Wall-clock schedule and dispatch-window preflight

systemd Calendar Timer & Activation Window Auditor

Test the calendar expression and the timer behavior around it: local clock transitions, randomized delay, accuracy coalescing, missed-run persistence, and the exact units you plan to install.

Multiple expressions use OR semantics

Describe the timer

One expression per line, up to 24. Blank lines and lines beginning with # are ignored.

Used only where an expression has no timezone suffix.

Models whether a persistent timer would request one catch-up activation.

An absolute command line is inserted as inert text. Nothing is executed in the browser.

Enter an expression or load the teaching timer.

Local and inert: expressions, command lines, unit names, schedules, reports, and generated files stay in this browser tab. The tool never runs a command, writes a unit, contacts a service manager, or reads the target host clock.

Why the configured time is not always the dispatch time

For calendar timers, OnCalendar= establishes the nominal wall-clock event. RandomizedDelaySec= then adds a value from its configured interval. After that, AccuracySec= allows systemd to place the event within a host-stable coalescing window to reduce wakeups. The default accuracy is one minute, so an expression alone does not promise exact-second dispatch.

Timezone and daylight-saving evidence

An explicit UTC or IANA timezone suffix makes the intended wall clock portable. During a forward transition, a matching local time may not exist. During a backward transition, the same local clock value may correspond to two distinct UTC instants. This evaluator reports both cases rather than silently forcing one interpretation.

Persistent timers catch up once

When Persistent=true, systemd records the prior trigger time and can activate the service when the timer returns if at least one event was missed. Multiple missed calendar events do not become an automatic replay queue; they produce one catch-up activation, still subject to randomized delay. The inactive-interval input makes that distinction visible.

Authoritative confirmation

The grammar and behavior model follows the official systemd.time calendar documentation and systemd.timer unit documentation. Before installing a generated unit, run systemd-analyze calendar 'EXPRESSION' and inspect systemctl list-timers on the actual target, because supported syntax and timer behavior depend on that host's systemd release and configuration.

Validation boundary

This is a bounded independent evaluator, not libsystemd or a service manager. It supports whole-second calendar lists, ranges, repetitions, weekdays, shortcuts, last-day selectors, UTC, browser-local, and browser-supported IANA zones. It intentionally rejects fractional seconds and does not expand systemd specifiers, parse drop-ins, model monotonic On*Sec= triggers, know the machine ID used for fixed randomization, reproduce host timer slack/coalescing, prove RTC wake support, check executable existence or permissions, or install and enable units.

Frequently asked questions

Why does the tool show a range instead of one randomized time?

The random value and accuracy placement belong to the target service manager. Showing an exact browser-generated timestamp would be false precision.

Should I set AccuracySec=1us for exact timing?

It minimizes systemd's coalescing allowance, but kernel scheduling, timer slack, load, suspend state, and service startup still affect execution.

Does FixedRandomDelay make every machine use the same offset?

No. The stable value derives from machine, manager-user, and unit identity, so it is intended to differ across those identities.

Can the generated service safely run my command?

The generator only places your text in ExecStart=. You must review quoting, privileges, paths, sandboxing, and service semantics on the target system.

Audit kubeconfig merge behavior · Browse systems and forensics tools