The difference in one sentence
Cron schedules by wall-clock time. Anacron schedules by elapsed period.
If you want a job to run "every day at 2 AM," use cron — it'll fire exactly at 2 AM. If you want a job to run "once every day, even if my laptop was off at 2 AM," use anacron — it'll run the job once per 24-hour period whenever the system is up.
Side-by-side comparison
| Cron | Anacron | |
|---|---|---|
| Granularity | Minute | Day (at minimum) |
| Specific time of day | Yes | No |
| Catches missed runs | No | Yes |
| Needs always-on system | Yes | No |
| Frequency | From every-minute to yearly | Daily, weekly, monthly only |
| Configured in | crontab -e or /etc/crontab | /etc/anacrontab |
Anacron syntax
An anacron entry looks nothing like a cron expression. It's period delay name command:
# /etc/anacrontab # period_in_days delay_in_minutes job-identifier command 1 5 daily.backup /usr/local/bin/backup.sh 7 10 weekly.cleanup /usr/local/bin/cleanup.sh 30 15 monthly.report /usr/local/bin/report.sh
Reads as: "Run backup.sh at most once per day, 5 minutes after anacron determines it's due."
How they work together
On most Linux distributions, both are running. The default /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/ directories are actually handled by anacron, not cron — that's why those run even after the laptop has been off all weekend.
Regular crontab entries are handled by cron and will miss runs if the system is off.
When to use cron
- Always-on servers
- Jobs that must run at a specific time (3 AM precisely)
- Sub-daily frequency (every hour, every 5 minutes)
- Cloud VMs (which never sleep)
When to use anacron
- Laptops and desktops that sleep or shut down
- Intermittent servers
- Jobs where "once per day" matters more than "at 3 AM"
- Maintenance tasks that should catch up after downtime
The modern alternative: systemd timers
Systemd timers with Persistent=true combine the best of both — cron-style precision with anacron-style catch-up. See our systemd timers guide.