Why Systemd Timers Are Silently Taking Over Your Cron Jobs

You probably still have cron jobs running. And maybe they still work fine. But for the past few years, a quiet migration has been underway in the Linux world: systemd timers are eating cron's lunch. And once you see why, you'll probably start moving your own tasks over too.

Cron has been the go-to scheduler since the 1970s. It's simple, predictable, and everywhere. But systemd timers offer something cron never could: deep integration with the rest of your system's service management. Here's what that means in practice.

The Hidden Power of OnCalendar

Cron's syntax is famously terse: 0 2 * * * /path/to/script.sh. Systemd timers use a more readable format called OnCalendar. Instead of five cryptic fields, you write:

OnCalendar=Mon..Fri 02:00:00

That's "every weekday at 2 AM." You can also do clever stuff like:

OnCalendar=*-*-* 00,12:00:00
OnCalendar=Sun *-*-* 03:00:00

But the real superpower isn't readability — it's failure handling.

What Happens When a Cron Job Fails?

If a cron job fails — say the system was off at 2 AM — it's gone. Maybe it retries at the next scheduled run, maybe not. Systemd timers, on the other hand, come with built-in persistent timers. You set Persistent=true in your timer unit, and systemd will run the missed job as soon as the system wakes up. This alone is a game-changer for laptops, VPS instances that get stopped, or systems that suspend overnight.

Dependency Chains Without Shell Scripting

Ever written a cron job that checks "is the database running? If not, wait and retry"? Systemd timers integrate with systemd's service dependencies natively. Your timer triggers a service unit. That service unit can Requires=postgresql.service or After=network-online.target. No more polling loops or sleep commands — it just waits for the dependency to be ready.

Here's a minimal example. First, the timer unit (backup.timer):

[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Then the service it triggers (backup.service):

[Unit]
Description=Run backup script
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

That's it. Enable the timer with systemctl enable backup.timer --now, and your backup runs daily, missing nothing, and only after the network is up.

Built-in Logging and Monitoring

Cron output goes to local mail (which often gets discarded) or to log files you set up yourself. Systemd logs everything automatically with journalctl. To see when the last backup ran and what happened:

journalctl -u backup.service --no-pager

Or check the timer's status:

systemctl list-timers --all

This outputs a neat table showing when each timer last ran and when it will next run. No more parsing cron logs or wondering if a job is still scheduled correctly.

Randomization — Cron's Secret Pain Point

Want to avoid the "top of the hour stampede" where every cron job on the planet fires at once? Cron has no built-in jitter. Systemd timers do:

RandomizedDelaySec=300

This adds up to 5 minutes of random delay before the job runs. Your servers will thank you when they're not all hitting the database at :00 past the hour.

Testing Without Waiting

One of cron's biggest annoyances: you set a job for 2 AM, then you have to either change the time to test it, or wait impatiently. Systemd lets you fire a timer's service immediately:

systemctl start backup.service

If it fails, you see the error right away. The timer itself stays scheduled as normal.

When Should You Still Use Cron?

Systemd timers aren't perfect. They're tied to systemd — you won't find them on Docker containers using a minimal base image, or on older distributions. If you need a scheduler that works across different init systems (like inside containers or on BSD), cron still wins.

Also, cron is simpler to set up if you just need "run this script every hour and never think about it again." For a single job, creating two files (timer + service) feels heavy. But for any real automation — backups, cleanups, monitoring checks, data syncs — the extra setup buys you reliability and visibility that cron simply can't match.

The Bottom Line

Systemd timers aren't a flashy new feature. They've been available since systemd v197 (released in 2013). But they've matured into a serious cron replacement. If you're deploying new automation today, there's a strong case for writing a timer unit instead of a crontab line. Your future self will appreciate the logging, the dependency handling, and the fact that missed jobs actually retry instead of vanishing into the void.

Cron isn't dead. But it's becoming legacy.