What Is a Cron Job? Complete Guide to Scheduling Tasks in Linux

A cron job is a task that is scheduled to run automatically on a Linux or Unix-based server at a specified time or interval. The name comes from Chronos, the Greek word for time. Cron jobs are used to automate repetitive tasks: sending reports, clearing temporary files, running database backups, fetching data from external APIs, and sending scheduled emails.

Cron is available on virtually every Linux distribution, macOS, and most Unix-based operating systems by default. It runs as a background service (called the cron daemon) that wakes up every minute, checks whether any scheduled jobs are due to run, and executes them. On modern Linux systems using systemd, the cron daemon is often replaced or supplemented by systemd timers, but traditional cron is still widely used and supported.

A single server may have dozens or hundreds of cron jobs defined across multiple users. System administrators define system-wide cron jobs for maintenance tasks. Developers define application-level cron jobs for data pipelines, cache warming, cleanup routines, and scheduled notifications. Operations teams use cron to automate infrastructure tasks like log rotation, certificate renewal with Certbot, and health check pings.

The cron daemon (crond on most systems) starts automatically when the server boots and runs continuously in the background. Every minute, it reads all crontab files — one per user plus system-wide cron directories — and checks whether any scheduled job matches the current time. If a match is found, it executes the corresponding command in a new process.

Cron reads job definitions from several locations. Each user has a personal crontab file managed with the crontab command. System-wide jobs are defined in /etc/crontab and in files placed in /etc/cron.d/. The directories /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/ contain scripts that run at those fixed intervals — drop a script into /etc/cron.daily/ and it will run once per day without writing a cron expression.

Each cron job runs in a minimal shell environment. The PATH variable is usually limited to /usr/bin and /bin, which is much shorter than your interactive shell PATH. Environment variables you have set in your .bashrc or .profile are not available in cron jobs. The working directory is typically the home directory of the user the job runs as. These differences are the most common source of cron jobs that work in the terminal but fail silently when run by cron.

A cron job definition has six parts: five time fields followed by the command to run. The five time fields specify when the job should execute: minute, hour, day of month, month, and day of week. They are written left to right in that order, separated by spaces, followed by the command.

The minute field accepts values 0 through 59. The hour field accepts 0 through 23 (using 24-hour format). The day-of-month field accepts 1 through 31. The month field accepts 1 through 12 or the three-letter abbreviations jan through dec. The day-of-week field accepts 0 through 7 (both 0 and 7 represent Sunday) or the three-letter abbreviations sun through sat.

An asterisk (*) in any field means every valid value for that field — every minute, every hour, every day. A value in a field means only that specific value. So 0 * * * * /path/to/script.sh runs the script at minute zero of every hour (i.e., on the hour). And 30 9 * * 1 /path/to/script.sh runs the script at 9:30 AM every Monday.

The asterisk (*) is the wildcard and means every possible value for that field. A slash (/) is used for step values: */5 in the minute field means every 5 minutes (0, 5, 10, 15... 55). A hyphen (-) defines a range: 1-5 in the day-of-week field means Monday through Friday. A comma (,) separates a list of values: 0,15,30,45 in the minute field means at minutes 0, 15, 30, and 45.

These special characters can be combined. 0-30/5 * * * * runs every 5 minutes but only during the first 30 minutes of each hour. 0 9-17 * * 1-5 runs every hour from 9 AM to 5 PM on weekdays. Understanding these combinations is the key to writing complex schedules without resorting to multiple separate cron entries.

Some cron implementations support an additional special character: the L (last) and W (nearest weekday) modifiers. These are available in some enhanced cron implementations and in job scheduling frameworks like Quartz (Java) and the cron syntax used in GitHub Actions, AWS EventBridge, and Azure Logic Apps, but are not part of the original POSIX cron specification and are not available in standard Linux cron.

Most modern cron implementations support shorthand aliases for common schedules. @reboot runs the command once when the server starts. @hourly is equivalent to 0 * * * *. @daily is equivalent to 0 0 * * *. @weekly is equivalent to 0 0 * * 0. @monthly is equivalent to 0 0 1 * *. @yearly (or @annually) is equivalent to 0 0 1 1 *.

These shortcuts are more readable than the equivalent five-field expressions and should be used when they match the schedule you need. @reboot in particular is useful for starting services or scripts that should run once on server startup and cannot be managed with systemd services.

When writing cron expressions for cloud schedulers like AWS EventBridge, GitHub Actions, or Google Cloud Scheduler, note that these platforms sometimes use a six-field format that adds a seconds field at the beginning or a year field at the end. Always check the documentation for the specific platform — a standard Linux cron expression may not work without modification.

Run a database backup every day at 2 AM: 0 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1. The >> appends stdout to a log file. The 2>&1 redirects stderr to stdout so errors also go to the log.

Clear a temporary directory every Sunday at midnight: 0 0 * * 0 find /var/tmp/app-cache -type f -mtime +7 -delete. This deletes files in the cache directory that are older than 7 days. Run on Sundays to avoid disrupting weekday activity.

Send a weekly report every Monday at 9 AM: 0 9 * * 1 /usr/local/bin/send-weekly-report.py. Ping a website every 5 minutes and alert if it goes down: */5 * * * * /usr/local/bin/check-uptime.sh. Run a job on the first day of every month at 6 AM: 0 6 1 * * /usr/local/bin/monthly-invoice.sh.

To create a cron job, run crontab -e in the terminal. This opens your personal crontab file in the default text editor (usually nano or vi). Add one cron job definition per line using the five-field time format followed by the command. Save and exit the editor to install the new cron jobs. The cron daemon picks up the changes automatically without needing a restart.

To list all current cron jobs for the current user, run crontab -l. To remove all cron jobs for the current user, run crontab -r (be careful — this removes everything with no confirmation). To edit the crontab for a specific user as root, run crontab -u username -e. To list another user cron jobs, run crontab -u username -l.

When writing the command in a cron job, always use absolute paths to both the executable and any files it references. Do not rely on aliases or shell functions defined in your .bashrc. If the script uses tools in /usr/local/bin, include that in the PATH at the top of the crontab file or use the full path in the command: /usr/local/bin/python3 /home/user/scripts/job.py instead of python3 scripts/job.py.

Cron runs jobs in a minimal environment with a very short PATH. The default PATH in cron is usually /usr/bin:/bin, which does not include /usr/local/bin, /usr/sbin, or user-specific paths like /home/user/.local/bin. This is the most common reason a command works in the terminal but fails in cron — the cron job cannot find the executable.

To fix this, either use full absolute paths for every command in your cron job, or set the PATH variable at the top of your crontab file. Add a line like PATH=/usr/local/bin:/usr/bin:/bin before any job definitions. This path applies to all jobs in the crontab file. You can also set other environment variables the same way: MAILTO=user@example.com, HOME=/home/user, SHELL=/bin/bash.

If your script uses pyenv, nvm, rbenv, or any other version manager, those tools are typically loaded by your shell profile (.bashrc, .profile, .nvm/nvm.sh) which cron does not source. You must either activate the version manager explicitly in the cron command, use the full path to the version-managed binary (e.g., /home/user/.nvm/versions/node/v20.0.0/bin/node), or wrap the job in a small shell script that sources the necessary profile files.

By default, cron sends any output from jobs to the user email on the local system. On most servers without a local mail server configured, this email is dropped. To capture output for debugging, redirect stdout and stderr to a log file in the cron command: 0 * * * * /path/to/script.sh >> /var/log/myjob.log 2>&1. The >> appends to the log rather than overwriting it. The 2>&1 sends stderr to the same file as stdout.

To check the cron daemon logs to see whether jobs are being triggered, look in /var/log/syslog (Debian/Ubuntu) or /var/log/cron (CentOS/RHEL). Run grep CRON /var/log/syslog or tail -f /var/log/cron to see recent cron activity. These logs show when each job was started but not what output it produced.

The most common debugging checklist for a cron job that does not run: verify the cron expression is correct using a cron expression tester; verify the script is executable (chmod +x /path/to/script.sh); verify the PATH includes all needed executables; verify the working directory assumptions are correct; verify environment variables are set; check whether the cron daemon is running (systemctl status cron or service crond status); and review the cron log for error messages about the job.

Cron is the right tool for simple, time-based task scheduling on a single server. It becomes a poor fit in several situations: when you need a job to run only once (use the at command instead), when you need sub-minute scheduling (cron minimum interval is one minute), when jobs need to run across multiple servers with coordination and deduplication, or when you need retry logic and failure handling.

systemd timers are a modern alternative on systems using systemd. They offer more precise timing (including sub-minute intervals), better logging through journald, dependency management, and the ability to catch up on missed runs after the system was off. For new systems where cron and systemd timers are both available, systemd timers are often the better choice for system-level tasks.

For application-level job scheduling in web applications, purpose-built tools are usually better than cron. BullMQ, Sidekiq, Celery Beat, and similar task queue schedulers provide retries, priority queues, monitoring, and failure handling that cron lacks. Cloud-native options like AWS EventBridge, Google Cloud Scheduler, and GitHub Actions scheduled workflows are better for distributed systems and teams that want to manage schedules as code in version control.