The essentials
Quick reference
One focused task per row. Jump to the related section for complete, working examples.
| Use | Syntax | Examples |
|---|---|---|
| List timers | systemctl list-timers --all | View examples |
| Inspect one timer | systemctl status backup.timer | View examples |
| Read timer properties | systemctl show backup.timer -p NextElapseUSecRealtime -p \
LastTriggerUSec -p Triggers | View examples |
| Validate a calendar | systemd-analyze calendar 'Mon..Fri 02:00' | View examples |
| Calendar schedule | OnCalendar=Mon..Fri *-*-* 02:00:00 | View examples |
| Catch a missed run | Persistent=true | View examples |
| Delay after boot | OnBootSec=15min | View examples |
| Delay after activation | OnUnitActiveSec=6h | View examples |
| Set timing accuracy | AccuracySec=1min | View examples |
| Spread starts | RandomizedDelaySec=30min | View examples |
| Keep host delay stable | FixedRandomDelay=true | View examples |
| Select activated unit | Unit=backup.service | View examples |
| Enable and start timer | sudo systemctl enable --now backup.timer | View examples |
| Test work directly | sudo systemctl start backup.service | View examples |
| Read job logs | journalctl --unit=backup.service --since=today | View examples |
A systemd timer activates another unit, usually a same-named oneshot service. Separate schedule from work, express dependencies and privileges in the service, validate calendar expressions before deployment, and inspect both timer activation history and service exit status. Timers are not a queue: define overlap, missed-run, and retry behavior explicitly.
Step by step
Detailed examples
Inspect timer and activated service as separate units
list-timers reports activations known to the current manager. A waiting timer can be healthy while its service repeatedly fails. Inspect timer properties, service status, journal, and unit source together; use --user for per-user manager timers rather than system units.
systemctl list-timers --all
systemctl status backup.timer --no-pager
systemctl status backup.service --no-pager
systemctl show backup.timer -p NextElapseUSecRealtime -p LastTriggerUSec -p TriggersKeep schedule configuration out of the service
A timer commonly named backup.timer activates backup.service. The service should define executable, user, working directory, environment, timeouts, and security controls and remain safe to start manually. Type=oneshot represents finite work; avoid backgrounding a command that systemd must supervise.
[Unit]
Description=Create the application backup
ConditionPathIsDirectory=/srv/app
[Service]
Type=oneshot
User=backup
Group=backup
ExecStart=/usr/local/libexec/app-backup
TimeoutStartSec=2h
Nice=10Validate realtime schedules and missed-run semantics
OnCalendar follows systemd calendar syntax and is affected by the configured timezone unless an expression specifies one. AccuracySec permits coalescing, so it is not a maximum delay guarantee. Persistent stores the last trigger timestamp and performs one catch-up activation after downtime, not one activation for every missed interval.
[Unit]
Description=Run application backup on weekdays
[Timer]
OnCalendar=Mon..Fri *-*-* 02:00:00
Persistent=true
AccuracySec=5min
Unit=backup.service
[Install]
WantedBy=timers.targetUse monotonic timers for elapsed intervals
OnBootSec, OnStartupSec, OnActiveSec, and OnUnitActiveSec schedule relative to lifecycle events and are not disrupted by wall-clock corrections. Combining directives creates multiple trigger paths. If a service is still active when its timer elapses, systemd does not start a second instance of the same service.
[Timer]
OnBootSec=15min
OnUnitActiveSec=6h
AccuracySec=5min
Unit=cache-refresh.serviceSpread fleet load without losing cadence intent
RandomizedDelaySec delays activations within a window; FixedRandomDelay can make the offset stable for the timer and machine. Combine jitter with sufficient AccuracySec and service timeouts. Randomization reduces thundering herds but does not cap concurrent backend work across hosts.
[Timer]
OnCalendar=*-*-* 01:00:00
RandomizedDelaySec=45min
FixedRandomDelay=true
Persistent=trueValidate, reload, then enable the timer—not the oneshot service
Install unit files or drop-ins atomically, run systemd-analyze verify, reload the manager, then enable and start the timer. Enabling a timer controls boot activation; the triggered service normally does not need enablement. Verify the computed next run after deployment.
sudo systemd-analyze verify /etc/systemd/system/backup.service /etc/systemd/system/backup.timer
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer --allTest the service directly and define overlap recovery
Start the service manually before relying on scheduling and inspect its exit status. Timers do not automatically retry failed jobs unless service restart or another activation does so. Use locking or service identity where work can overlap with external invocations, and monitor last success rather than only timer activation.
sudo systemctl start backup.service
systemctl show backup.service -p Result -p ExecMainStatus -p ActiveEnterTimestamp
journalctl --unit=backup.service --since=today --no-pagerSources and further reading
References
Authoritative documentation used to verify and expand this cheat sheet.
Help us improve
Found a typo or missing example?
Tell us what would make this cheat sheet clearer, more complete, or more useful.