Decide whether a systemd calendar timer should catch up after downtime

Persistent scheduling can trigger missed work when the timer becomes active again.

Source facts

The Debian systemd.timer manual states that Persistent stores the last trigger time on disk. When reactivated, a calendar timer can immediately trigger work that would have run while it was inactive. This behavior applies to OnCalendar timers and remains subject to RandomizedDelaySec. It is a catch-up mechanism rather than replay of every missed occurrence.

Source: Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages.

Applicability

Review Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.

DSE recommendation

DSE recommends choosing catch-up behavior with the task owner. A missed inventory reconciliation and a time-sensitive external notification may need different policies. Make the service idempotent where repeated execution is possible, and define whether stale work should be skipped by the application. Keep the persisted state in the timer’s retirement procedure. Account for random delay when explaining why an activated timer has not yet started work, and monitor successful completion separately from the presence of a scheduled trigger.

Verification

In a nonproduction timer, disable activity across a scheduled occurrence and then reactivate it. Compare behavior with the intended Persistent setting and inspect the next trigger and service result. Confirm the application handles a delayed execution appropriately without claiming every missed interval was individually processed. Retain the timer’s timestamp state, configured random delay and actual task result together. Ask the task owner to approve delayed execution explicitly, including the rule for rejecting stale business work when that is necessary.

Official reference

Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.