# Decide whether a systemd calendar timer should catch up after downtime

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

- Canonical URL: https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:15:23+00:00
- Modified: 2026-10-20T18:34:33+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html).

## 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](https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html). Reviewed October 20, 2026.

## Primary reference

- Name: Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages
- Authority: manpages.debian.org
- URL: https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Decide whether a systemd calendar timer should catch up after downtime,” DSE Security, https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.