Cron has been the standard scheduler on Unix for decades. systemd timers are newer, more powerful, but also more verbose.
Cron wins when
Cron is perfect for one-line scripts that need to run on a simple schedule. Writing:
0 3 * * * /usr/local/bin/backup.sh
is fast, requires no other files, and works on every Unix-like system since the 1970s.
systemd timers win when
You want any of these:
- Logging integrated with journalctl
- Dependencies on other units (
After=network-online.target) - Resource limits (
MemoryMax=,CPUQuota=) - Randomized delays to avoid thundering herd (
RandomizedDelaySec=) - The ability to manually trigger with
systemctl start - Catch-up behavior after system was off (
Persistent=true)
Minimal systemd timer example
/etc/systemd/system/backup.service:
[Unit]
Description=Daily backup
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
/etc/systemd/system/backup.timer:
[Unit]
Description=Run daily backup at 3am
[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=1800
Persistent=true
[Install]
WantedBy=timers.target
Then systemctl enable --now backup.timer.
My personal rule
For anything more than a trivial one-liner, or anything that matters, I reach for systemd timers. Cron is still fine for simple developer convenience scripts, but the operational visibility of systemd makes it worth the extra lines of config.