Cron vs systemd timers: which scheduler should you use on modern Linux?

How this is calculated

Systemd timers support features cron doesn't: randomized start delays (RandomizedDelaySec) to avoid thundering herds, monotonic timers such as OnUnitActiveSec that fire relative to the unit's last activation rather than wall clock time, sub-second precision, and proper dependency management between services. OnUnitInactiveSec is the separate option measured from the unit's last deactivation. Cron's advantages are that it works on every Unix-like system including macOS, FreeBSD, and minimal containers, and its syntax is known by every sysadmin. If you're scheduling on a single server and don't need the advanced features, cron is fine. If you're deploying to a fleet of Linux servers and need coordinated timing, randomized jitter, or sub-minute scheduling, systemd timers are the right choice.

Verdict

The split comes down to features versus ubiquity. systemd adds RandomizedDelaySec to dodge thundering herds, OnUnitActiveSec for monotonic timing relative to the unit's last activation, sub-second precision, and service dependency management. cron still runs on macOS, FreeBSD, and minimal containers where systemd isn't present. Pick cron when you need that reach, and pick timers when you need the jitter and precision.