systemd timers — replacing cron with calendar and monotonic schedules · Linux

systemd timers are the modern replacement for cron. They integrate with the dependency graph, log to the journal, support calendar arithmetic and monotonic schedules, and handle downtime gracefully.

Timer + service pair

A timer unit has the same name as a service unit, with .timer suffix. When the timer fires, systemd activates the matching service.

# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup

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

# /etc/systemd/system/backup.timer
[Unit]
Description=Nightly backup timer

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=15min

[Install]
WantedBy=timers.target

Service impact possibleenable timer— enable --now on the .timer unit activates the timer and the matching service's first run. After this, backup.service runs at 02:00 every night.

$ systemctl daemon-reload; systemctl enable --now backup.timer

Illustrative output

OnCalendar — real-time scheduling

The OnCalendar= directive uses the systemd time syntax (described in man 7 systemd.time):

Expression	Meaning
`--* 02:00:00`	Every day at 02:00
`Mon..Fri --* 06:00:00`	Weekdays at 06:00
`Sat,Sun --* 00:00:00`	Weekends at midnight
`*-01-01 00:00:00`	January 1st every year
`*:0/15`	Every 15 minutes (any hour)
`2026-08-09 12:00:00`	Specific date and time

Read-only / Safesystemd-analyze calendar— systemd-analyze calendar parses a calendar expression and shows the next elapse. Use this to validate every timer expression before activating it — a typo can make a job never run, or run every minute.

$ systemd-analyze calendar '*-*-* 02:00:00'

Original form: *-*-* 02:00:00
Normalized form: *-*-* 02:00:00
Next elapse: Mon 2026-08-11 02:00:00 UTC
(in UTC): Mon 2026-08-11 02:00:00 UTC
From now: 1 day 13 hours

Illustrative output

Monotonic schedules

Monotonic schedules trigger after an event, not at a specific time. Useful for “do this N seconds after boot” or “N seconds since this service last ran”:

Directive	Trigger
`OnBootSec=`	N seconds after system boot
`OnStartupSec=`	N seconds after systemd startup
`OnActiveSec=`	N seconds after the timer itself activated
`OnUnitActiveSec=`	N seconds after the matching service’s last activation
`OnUnitInactiveSec=`	N seconds after the matching service’s last deactivation

[Timer]
OnBootSec=5min
OnUnitInactiveSec=30min

This fires 5 minutes after boot, then every 30 minutes after the last service deactivation. Useful for housekeeping tasks that should run shortly after boot and at regular intervals thereafter.

Persistent — catch-up after downtime

Read-only / Safepersistent timer— Persistent=true means: if the host was off when the timer was supposed to fire, run the service once on next boot to catch up. logrotate is the canonical case — if a host is down overnight, log rotation should happen when it boots, not be skipped.

$ cat /etc/systemd/system/logrotate.timer

[Unit]
Description=Daily rotation of log files

[Timer]
OnCalendar=daily
AccuracySec=1min
Persistent=true

[Install]
WantedBy=timers.target

Illustrative output

Persistent=true catches up once, not once per missed run

man systemd.timer is precise about this: systemd stores the time the unit was last triggered, and on activation triggers it immediately “if it would have been triggered at least once during the time when the timer was inactive”. One timestamp, one catch-up. A host down for three days with a daily timer runs the job once on boot, not three times.

That cuts two ways in production.

It is safer than it looks. Catch-up produces a single extra run, so the risk with a non-idempotent job is one duplicate, not a burst — still a reason to think before enabling it on a notification or a migration, but not the pile-up it is often described as.

It is also weaker than it looks, and that is the trap. A job that must produce one artefact per day — a daily report, a per-day billing roll-up, a dated backup — cannot use Persistent= to backfill. It will run once, produce today’s artefact, and the three missed days stay missing with nothing logged as failed. If the gap matters, the job itself has to detect and fill it.

For jobs where any catch-up is unwanted, leave Persistent=false and accept that missed runs are missed. Or use OnUnitInactiveSec= to schedule “30 minutes after the service last ran”, which sidesteps wall-clock catch-up entirely.

systemctl clean --what=state <timer> removes the stored timestamp, which is how you stop a catch-up you do not want on the next boot.

RandomizedDelaySec — avoiding the thundering herd

A shared maintenance window across a fleet — every host running logrotate at exactly 02:00:00 — concentrates load on central services. RandomizedDelaySec=15min randomises the actual activation within a 15-minute window after the scheduled time.

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=15min

This is the default for many vendor timers on modern distributions. Adopt it for your own fleet-wide timers.

Listing and inspecting timers

Read-only / Safelist-timers— systemctl list-timers shows every active timer with its next elapse, last activation, and the matching service. --all includes inactive timers. Use this for the post-boot health check alongside list-units --state=failed.

$ systemctl list-timers --all

NEXT                         LEFT     LAST                         PASSED   UNIT                         ACTIVATES
Mon 2026-08-11 02:00:00 UTC  1d 13h   Mon 2026-08-09 02:00:12 UTC  12h ago  logrotate.timer              logrotate.service
Mon 2026-08-11 00:00:00 UTC  1d 11h   Mon 2026-08-09 02:00:12 UTC  12h ago  backup.timer                 backup.service
Mon 2026-08-11 00:30:00 UTC  1d 12h   n/a                          n/a      fstrim.timer                 fstrim.service
...

Illustrative output

Production discipline

Practice	Why
Use `OnCalendar=` for wall-clock schedules; `OnUnitActiveSec=` for delay-after-event.	Cron only does wall-clock; systemd timers handle both natively.
Add `RandomizedDelaySec=` to fleet-wide timers.	Avoids thundering-herd at top of hour.
Use `Persistent=true` only for idempotent jobs, and never to backfill per-day artefacts.	Catch-up fires the unit once, however many runs were missed - one duplicate for a non-idempotent job, and no backfill at all for a job that owes one artefact per day.
Validate every expression with `systemd-analyze calendar`.	Typos produce silent failures.
Add `WantedBy=timers.target` so the timer is enabled at boot.	Without it, the timer is inactive after a reboot.

Timer + service pair

OnCalendar — real-time scheduling

Monotonic schedules

Persistent — catch-up after downtime

RandomizedDelaySec — avoiding the thundering herd

Listing and inspecting timers

Production discipline

Knowledge check