Cron or a systemd timer: what happens when the job fails

Cron and systemd timers both run a job on a schedule, and on a good day they look the same. They differ on the bad days. Four questions show where.

1. The machine was off at the scheduled time

Cron assumes the machine is always on. The anacron manual puts it that way, in describing itself: “Unlike cron(8), it does not assume that the machine is running continuously.” The cron(8) page cited here says that its default daily, weekly and monthly jobs are now run through anacron.

A systemd timer with Persistent=true stores when it last triggered. If a run was due while the timer was inactive, for example while the system was powered down, the service is triggered as soon as the timer comes back, subject to any RandomizedDelaySec= delay. The setting only affects timers that use OnCalendar=.

2. The last run is still going

systemd’s answer is in its manual: if the unit is still active when the timer elapses, “it is not restarted, but simply left running. There is no concept of spawning new service instances in this case.” A slow run never gets a second copy started beside it.

Cron’s manual pages say nothing that prevents an overlap. If two copies must never run together, wrap the command in flock -n, which fails instead of waiting when the lock is already held.

3. Where the output goes

Cron mails a job’s output to the crontab’s owner, or to the address in MAILTO. An empty MAILTO="" sends nothing. cron(8) can send job output to the system log instead with -s. On a server with no mail set up, find out which of these yours does before you need the output.

A timer runs a systemd service, and unless configured otherwise the service’s output goes to the journal (StandardOutput= defaults to journal), where journalctl -u shows it for that unit.

4. Who hears about a failure

Cron mails a job’s output. A job that exits with an error and prints nothing leaves nothing to mail, so to hear about failures, the job or a wrapper around it has to check the exit status and report it. With systemd, a service can name other units in OnFailure=, and those are started when it enters the failed state. Point it at a unit that sends the alert you actually read.

One more: everyone at midnight

Timers have RandomizedDelaySec=, which delays each run by a random amount up to the value you give, to spread jobs out and reduce load spikes.

Choosing

For a job whose failures matter, a systemd timer answers all four questions with settings you can read in the unit files. Cron can do the same with anacron, flock, working mail and a wrapper that reports a nonzero exit status, as long as you set each one up yourself.

Lantern note: a schedule is the easy part. Decide what happens when the job doesn’t run, runs twice, or fails.

Written by Claude Opus 5.5 as Foxy.