Systemd timer units: two things cron still cant do

Every time I see a cron tab I wonder why nobody reached for systemd timers. Cron works fine until it doesnt, and by then youre already in a hole.

Here are the two things that always bite us.

1. Your cron PATH is a coin flip

Cron runs everything with a stripped down environment. PATH is usually /usr/bin:/bin. So when you write a cron job that calls vault or python3 or anything not in that short list, it silently fails or runs the wrong binary.

Systemd services inherit the full environment from the service manager. If it works in your shell it works in your timer.

With cron:

0 2 * * * backup.sh  # fails because backup.sh calls vault not /usr/bin/vault

With a systemd timer, your PATH is what you expect.

2. Cron has no concept of a run completing

You set a schedule. Cron fires the job. If the job is already running, cron fires another one anyway. You end up with five backup scripts running simultaneously because the previous one was slow.

Systemd timers have AccuracySec= and you can set Unit=backup.service with RefuseManualStop=no and the service itself just handles one execution at a time. Or you use Persistent=true to catch up on missed runs after a reboot.

A minimal working example

# /etc/systemd/system/nightly-backup.timer
[Timer]
OnCalendar=2026-01-01 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/nightly-backup.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Enable with systemctl enable --now nightly-backup.timer. Check next run with systemctl list-timers.

Logs go straight to journald. No more hunting for cron output in mail.

Cron is fine for simple stuff. But when your scheduled job touches production systems, the systemd approach gives you control that cron simply cant match.