Timers

A systemd timer is a unit that activates another unit on a schedule. It is the systemd-native replacement for cron: instead of a crontab line, you write a .timer file that says when, paired with a .service file that says what. The timer never runs your command directly — it starts the matching service, and the service is where the command, the user, the environment, and the resource limits live. The pairing is by name: backup.timer activates backup.service unless you override the target with Unit=.

The operational payoff is that scheduled jobs become first-class units. They show up in systemctl list-timers, their output and exit status land in the journal instead of an emailed stdout, they inherit cgroup accounting and sandboxing, and a job that overruns its interval will not stack a second copy on top of the first the way two overlapping cron runs do. The cost is verbosity: every job is now two files instead of one crontab line, and the timer syntax has its own calendar grammar you have to learn.

The Timer and Service Pair

A timer unit carries a [Timer] section; the work goes in a sibling service. You enable and start the timer, not the service — the service is started on demand when the timer fires. A minimal pair for a nightly backup looks like this on Debian or Ubuntu, with both files under /etc/systemd/system/.

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

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

# /etc/systemd/system/backup.timer
[Unit]
Description=Run the nightly backup

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

The service is Type=oneshot because it runs to completion and exits rather than staying resident — that is the right type for batch work, and it lets systemd treat the run as finished only when the script returns. There is no [Install] section in the service, because you never enable it yourself; the timer pulls it in. Enable the timer with systemctl enable --now backup.timer, and it both starts now and survives reboot through timers.target.

Calendar Timers with OnCalendar

Calendar timers fire at wall-clock times using OnCalendar=, which is the direct analogue of a cron schedule. The grammar is DayOfWeek Year-Month-Day Hour:Minute:Second, with * as a wildcard, comma lists, ranges with .., and / for repetition. There are also named shortcuts: daily, weekly, monthly, and hourly expand to fixed times.

OnCalendar expression	Fires
*-*-* 02:30:00	Every day at 02:30
Mon..Fri 09:00	Weekdays at 09:00
*-*-* *:0/15	Every 15 minutes, on the quarter-hour
Mon *-*-* 00:00:00	Every Monday at midnight
*-*-01 04:00	The first of every month at 04:00

Always validate an expression before you trust it. systemd-analyze calendar 'Mon..Fri 09:00' parses the string, normalizes it, and prints the next elapse time — add --iterations=N to see several — so you can confirm a job lands when you think it does instead of discovering at 02:30 that you wrote the wrong field. The same tool catches the classic mistake of a time that never matches.

Monotonic Timers and Boot-Relative Schedules

Not every job belongs on a wall clock. Monotonic timers fire relative to an event rather than a calendar date, using directives like OnBootSec= (time after boot), OnStartupSec= (time after systemd itself started), OnUnitActiveSec= (time after the paired unit last ran), and OnUnitInactiveSec=. These are how you express "fifteen minutes after boot, then every six hours" without pinning to specific clock times.

[Timer]
# run 15 min after boot, then every 6 h afterwards
OnBootSec=15min
OnUnitActiveSec=6h

Monotonic timers do not understand Persistent= — that directive only applies to OnCalendar timers, because "did I miss a run" only has meaning against a wall clock. Mixing the two in one timer is legal and occasionally useful, but the common pattern is to pick one model per job: calendar timers for "at 02:30 nightly", monotonic timers for "a while after boot, then periodically".

Catch-up, Jitter, and Accuracy

Persistent=true records the last time a calendar timer ran in /var/lib/systemd/timers/. If the machine was off or asleep when the timer should have fired, the job runs once at next boot to catch up. This is the systemd answer to anacron, and it is the directive laptops and intermittently-on servers need — without it, a backup scheduled for 02:30 simply never happens on a machine that is powered down overnight.

RandomizedDelaySec= spreads a timer's fire time randomly across a window, which matters when a fleet of hosts all run the same calendar timer and would otherwise hammer a backup target or package mirror at exactly 02:30. AccuracySec= controls how loosely systemd is allowed to coalesce timer wakeups — the default is one minute, which lets the kernel batch wakeups and save power; set it to 1s only when a job genuinely needs second-level precision, because tighter accuracy means more wakeups.

Inspecting and Debugging Timers

systemctl list-timers is the single most useful command here: it lists every active timer with its next elapse time, the time left, the last time it ran, and the unit it activates. systemctl list-timers --all includes inactive ones. To see why a specific job did or did not run, read the journal for the service, not the timer, since the service is where the command executed.

# what is scheduled and when it next fires
systemctl list-timers --all

# did the last run succeed? full output of the job
journalctl -u backup.service

# trigger the job by hand, ignoring the schedule
systemctl start backup.service

Starting the .service by hand runs the job immediately and is the correct way to test it — starting the .timer only arms the schedule, it does not run the work. On Red Hat and Fedora the commands are identical; the only divergence from Debian and Ubuntu is unit placement conventions and the surrounding package names, not the timer mechanism itself.