Cron vs systemd Timers
Both schedule jobs on Linux. cron is simpler and universal; systemd timers integrate with journald logging, can catch up missed runs (Persistent=true), add randomized delays, and depend on other units. For anything beyond a basic schedule, timers are usually the better choice.
When cron wins
One line, available everywhere, nothing to learn: 0 2 * * * /path/backup.sh. Perfect for simple personal or legacy jobs.
When a timer wins
systemd timers give you journalctl -u mytask logging, Persistent=true to run jobs missed while the machine was off, RandomizedDelaySec to spread load, and OnCalendar with service dependencies.
Timer example
mytask.timer with [Timer]\nOnCalendar=*-*-* 02:00:00\nPersistent=true plus a matching mytask.service, then systemctl enable --now mytask.timer. The OnCalendar format replaces the five cron fields.
FAQ
Is a systemd timer better than cron?
For anything non-trivial, yes: timers log to journald, can run missed jobs (Persistent=true), add randomized delays, and depend on other units. cron wins on simplicity and universality.
How do I convert a cron job to a systemd timer?
Create a .service with your command and a .timer with OnCalendar (e.g. *-*-* 02:00:00) for 0 2 * * *, then systemctl enable --now mytask.timer.
Does a systemd timer catch up missed runs?
Yes, if you set Persistent=true the timer runs a job that was missed while the system was powered off. Plain cron does not.