Cron vs systemd Timers: When the Modern Scheduler Wins (and When It Doesn't)

It's 3 a.m. and your backup job didn't run. The crontab looks right, the logs are empty, and you're about to blame the scheduler. Cron has scheduled jobs since 1975, and on most Linux systems there's a newer option that fixes exactly the problems cron is known for: systemd timers. Understanding when to use which one saves you the 3 a.m. wake-up call.

What systemd Timers Do Better

systemd timers can run a job only after another service is up — say, back up the database but only once the database is running. That's a dependency, and cron has no concept of one. Timers also give you real logs through journalctl, calendar events that describe the next run in plain terms, and the option to run once, on a schedule, or only in a specific power state. The counter-intuitive part: timers are often assumed to use cron syntax, but they use calendar events, so a cron parser won't read them directly — check the syntax before you port an old job.

Where Cron Still Wins

Cron survives because it's simple and everywhere. One line, one meaning, portable across every Unix — a crontab file from a 1995 server still works today. If your job is "run this script at these times," cron is done in ten seconds, and the next person who reads it knows exactly what it does. Timers solve real problems; they also add a layer of complexity a simple job doesn't need. The unix timestamp tool helps sanity-check the times either way, and the hash generator confirms a job's output integrity when it matters.

How to Compare Them

Use cron for simple, portable, schedule-only jobs. Use systemd timers when you need dependencies, real logging, or calendar-aware scheduling. The mistake is choosing by fashion instead of need: a timer won't fix a job that never runs in cron if the problem is your timezone or your expression — we covered those traps in our guide to reading crontab schedules.