A systemd timer activates a service according to a schedule and gives you service status and journal evidence for the result. Use a timer for a defined maintenance task with a known runtime, privilege requirement and recovery behavior.
IN THIS ARTICLE
What you need before you begin
Prepare a tested script with absolute paths, a meaningful exit code and no embedded secrets. Decide its service account, working directory and schedule timezone. Remove or disable an older cron entry only after the replacement is validated so the job does not run twice.
01 Run a maintenance job with a systemd timer
- Create a dedicated oneshot service unit for the task. Set its User and WorkingDirectory where appropriate, and keep the script executable only by the intended operators.
- Create the matching timer unit with a deliberate calendar or monotonic schedule. Use Persistent only when catching up a missed calendar run is appropriate; not every maintenance task should run immediately after a long outage.
- Validate unit files with the installed systemd tooling and inspect calendar interpretation with
systemd-analyze calendar. Review daylight-saving and random-delay behavior if timing matters. - Run the service manually once and inspect its journal and application result. A zero exit code should represent actual successful work, not merely launching a background process.
- Reload unit definitions, enable and start the timer, then inspect
systemctl list-timers. Confirm the next and last activation are plausible. - Observe one scheduled execution and set up failure notification appropriate to the operation.
02 Example: inspect the next run and matching service for a timer
On a systemd-based Linux server, replace example-maintenance with the timer and service names you configured. These commands display the schedule, saved unit definitions and recent job output without enabling or manually starting the task.
systemctl list-timers --all example-maintenance.timer
systemctl cat example-maintenance.timer example-maintenance.service
sudo journalctl -u example-maintenance.service --since '-1 day' --no-pager -n 50Read the result: Confirm the timer points to the intended service and has a next run where appropriate. Check the service's User, WorkingDirectory and ExecStart against the application. A timer firing successfully does not mean the invoked job completed its business work.
For calendar schedules, review the server timezone and daylight-saving expectations. Persistent timers can run missed work after downtime, so decide whether that behaviour is suitable for the task. Retain the job's success marker or outcome in addition to the timer schedule.
Will a timer start a second copy while the same service is active?
It normally leaves an already-active target service running. Design the task and any other scheduler to avoid overlap, and review the scheduling behavior when a job takes longer than its interval.
Confirm the expected result
Confirm the timer is active, the service completes and its intended output is correct. Check permissions and ensure a still-running job is not duplicated by another scheduler. Record the schedule and responsible owner.
Troubleshoot unexpected results
If nothing runs, inspect both timer and service status, unit naming, clock synchronization and the actual calendar expression. A service that remains active after completion can prevent repeated activations. Disable the timer while fixing a harmful script; repeatedly forcing executions can duplicate work.