Cron vs systemd timers: which should you use?
systemd timers are the modern alternative to cron on Linux. Here's how they differ, what OnCalendar syntax looks like, and when to reach for each.
On most modern Linux distributions you have two schedulers available: classic cron and systemd timers. Both run tasks on a schedule; they differ in power, integration and complexity. Here's how to choose.
The quick answer
- Reach for cron for simple, portable, one-line jobs — it's everywhere, and a crontab entry takes seconds.
- Reach for systemd timers when you want proper logging, dependencies, control over missed runs, or resource limits — and you're already on a systemd distro.
What a systemd timer looks like
Where cron is one line, a systemd timer is two units: a .service that says what to run and a .timer that says when.
The service, /etc/systemd/system/backup.service:
[Unit]
Description=Nightly backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
The timer, /etc/systemd/system/backup.timer:
[Unit]
Description=Run backup nightly
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
Enable it with systemctl enable --now backup.timer, and check upcoming runs with systemctl list-timers.
OnCalendar vs cron syntax
Timers use OnCalendar instead of the five cron fields. The format is DayOfWeek Year-Month-Day Hour:Minute:Second:
| Schedule | cron | systemd OnCalendar |
|---|---|---|
| Every day at 2 AM | 0 2 * * * |
*-*-* 02:00:00 |
| Weekdays at 9 AM | 0 9 * * 1-5 |
Mon..Fri 09:00 |
| Every 15 minutes | */15 * * * * |
*:0/15 |
| First of the month | 0 0 1 * * |
*-*-01 00:00:00 |
There are also shortcuts (daily, weekly, hourly) and a handy checker: systemd-analyze calendar "Mon..Fri 09:00" prints the next elapse times.
Where timers win
- Logging is built in. Every run's output goes to the journal —
journalctl -u backup.serviceshows exactly what happened. No more redirecting to a log file by hand. - Missed runs.
Persistent=trueruns a job that was missed because the machine was off — cron just skips it. - Dependencies and ordering. A timer's service can depend on the network being up, a mount being ready, or another unit, using the full systemd dependency graph.
- Randomized delays.
RandomizedDelaySec=spreads load so a fleet of machines doesn't all fire at exactly the same second. - Resource control. The service can carry
MemoryMax=,CPUQuota=and sandboxing directives.
Where cron wins
- Simplicity. One line versus two files. For a quick job, that matters.
- Portability. cron exists on virtually every Unix-like system, including ones without systemd (Alpine, many containers, macOS, BSD).
- Familiarity. Nearly everyone can read a crontab;
OnCalendarand unit files have a learning curve.
Which should you choose?
If you're on a systemd distro and the job is important — it needs logs, must survive downtime, or depends on other services — use a timer. If it's a simple, self-contained task, or you need it to work anywhere, cron is still the pragmatic choice. Many systems happily run both. Whichever you pick, decode the schedule in the parser first so you know exactly when it fires.