A cron job is an automated task scheduled to run at specific times or intervals on a Linux system. The name comes from Chronos, the Greek god of time, and the cron daemon has been the standard Linux task scheduler for decades — quietly running backups, sending reports, cleaning temp files, and performing maintenance without any human intervention required.
Understanding cron jobs is essential for anyone managing Linux servers or automating repetitive workflows. This guide explains how cron works, how to read and write cron syntax, and how to avoid the common mistakes that cause scheduled tasks to fail silently.
How the Cron Daemon Works
Cron runs as a background service called crond (or cron on Debian-based systems). It wakes up every minute, checks all crontab files for tasks that match the current time, and executes them. The daemon reads from multiple locations:
- /etc/crontab — the system-wide crontab with an extra user field
- /etc/cron.d/ — directory for package-managed cron files
- /var/spool/cron/crontabs/ — per-user crontab files managed by the crontab command
- /etc/cron.hourly/, /etc/cron.daily/, etc. — drop-in script directories for common intervals
For most individual tasks, you will work with the user crontab edited via crontab -e. System-level tasks that need to run as root go into /etc/crontab or /etc/cron.d/.
Cron Job Syntax Explained
Every cron job line follows a fixed format. Misreading a single field sends your task running at the wrong time — or not at all:
* * * * * command_to_run
│ │ │ │ │
│ │ │ │ └── Day of week (0–7, where 0 and 7 = Sunday)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)Each field accepts specific values:
| Symbol | Meaning | Example |
|---|---|---|
| * | Any value | Every minute/hour/day |
| , | List separator | 1,15 = 1st and 15th |
| – | Range | 1-5 = Monday through Friday |
| / | Step value | */15 = every 15 minutes |
Reading Common Cron Expressions
The fastest way to internalize cron syntax is to read real expressions:
- 0 2 * * * — runs at 2:00 AM every day
- 30 8 * * 1-5 — runs at 8:30 AM Monday through Friday
- */15 * * * * — runs every 15 minutes, all day
- 0 0 1 * * — runs at midnight on the first of every month
- 0 3 * * 0 — runs at 3:00 AM every Sunday
A common mistake is placing a value in the wrong field. Writing 2 * * * * means “run at minute 2 of every hour” — not “run at 2 AM.” Always verify expressions using a cron calculator before deploying them on production systems.
Creating and Managing Cron Jobs
Edit your personal crontab with:
crontab -eThis opens the file in your default editor (usually nano or vim). Each line is one job. Add a job at the bottom, save, and exit — the change takes effect immediately.
To view your current crontab without editing:
crontab -lTo remove all jobs from your crontab (use with caution):
crontab -rRoot can view and edit any user’s crontab with the -u flag:
sudo crontab -u username -eWriting Reliable Cron Commands
Cron runs in a minimal environment. The PATH variable is stripped down, which means commands that work perfectly in your terminal may fail inside a cron job because the shell cannot find the executable. Always use full paths:
# Wrong — may fail in cron
0 2 * * * backup.sh
# Correct — explicit paths
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1The 2>&1 at the end redirects both stdout and stderr to the log file. Without output redirection, cron attempts to email output to the local user — and silently discards it if mail is not configured.
Setting the PATH at the top of a crontab file solves the environment problem across all jobs:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/binLinux Cron Job Tutorial: Practical Examples
Daily Backup at 3 AM
0 3 * * * /usr/bin/rsync -az /var/www/ /backup/www/ >> /var/log/rsync.log 2>&1This runs rsync every day at 3 AM and logs the output. A more sophisticated backup strategy — including incremental and offsite backups — is covered in the complete Linux server backup guide.
Disk Space Check Every Hour
0 * * * * df -h / | awk 'NR==2{print $5}' | grep -q "9[0-9]%" && echo "Disk nearly full" | mail -s "Disk Alert" [email protected]This checks the root partition usage every hour and sends an alert if usage exceeds 90%. For a complete overview of disk space monitoring tools and commands, the guide on how to check disk space in Linux provides additional context.
Clear Temp Files Weekly
0 0 * * 0 find /tmp -type f -mtime +7 -deleteThis deletes files older than seven days from /tmp every Sunday at midnight.
Special Cron Syntax and Shortcuts
Cron supports shorthand strings for common intervals, which are clearer than the five-field syntax:
| Shorthand | Equivalent | Meaning |
|---|---|---|
| @reboot | (none) | Run once at system startup |
| @hourly | 0 * * * * | Run every hour |
| @daily | 0 0 * * * | Run once per day at midnight |
| @weekly | 0 0 * * 0 | Run once per week on Sunday |
| @monthly | 0 0 1 * * | Run on the first of every month |
| @yearly | 0 0 1 1 * | Run on January 1st |
The @reboot entry is particularly useful for starting services or running initialization scripts when the server boots. If you are setting up a Debian server from scratch and want cron jobs as part of the initial configuration, the Debian server setup guide covers service management and post-install automation in detail.
Troubleshooting Cron Jobs That Do Not Run
Silent failure is the most frustrating aspect of cron. A job appears to be scheduled, nothing happens, and there is no obvious error. The most common causes:
- Wrong path to executable — use which command_name to find the full path
- Missing execute permission — run chmod +x /path/to/script
- Script has Windows line endings — use dos2unix to convert
- Environment variables missing — set PATH at the top of the crontab
- Cron service not running — check with systemctl status cron
Check the cron log to see what the daemon is actually doing:
grep CRON /var/log/syslog | tail -20Each executed job appears in this log with its timestamp and the command that ran. If a job ran but produced an error, redirect output to a log file and inspect it after the next scheduled execution.
If you are running Linux alongside Windows and want to understand how cron compares to Windows Task Scheduler, the guide on the best Linux replacements for Windows tools covers the ecosystem differences in detail.
When to Use Cron vs Systemd Timers
Modern Linux systems include systemd timers as an alternative to cron. Timers offer better logging through journald, dependency management, and more precise timing. For simple, recurring tasks, cron remains faster to set up and easier to read at a glance. For complex tasks with dependencies or those that need to run after a service is ready, systemd timers are the more capable tool.
Cron jobs are not going away — they are available on virtually every Linux system, well understood, and straightforward to debug. For the vast majority of scheduled automation tasks, cron is still the right choice.
