Skip to main content
You can schedule one-time jobs with at and recurring jobs with cron. In this article we cover a more modern, integrated approach using systemd timers — the systemd-native way to schedule tasks. systemd timers schedule jobs using the same framework that manages services on Linux. Compared with traditional cron jobs, timers offer improved logging, dependency control, integration with service units, and awareness of system state (boots, shutdowns, targets). Because timers are first-class systemd units, they participate in restart policies and the systemd journal, making them more flexible and reliable for many automation use cases.
A dark-themed presentation slide titled "Why Use Systemd Timers?" that lists three numbered benefits: built directly into systemd, triggers systemd service units, and integrates with the system journal, each with brief explanatory text. Each item is shown with a circular number icon and horizontal accent lines.
Think of a systemd timer as an alarm clock; the corresponding service unit is the action performed when the alarm goes off.
A dark-themed slide titled "SystemD Timers" that says "Think of them as alarm clocks," with a blue outline alarm-clock icon in the center. Below it is a line explaining that the service is the action performed when the alarm goes off.
A systemd timer always works together with a service unit:
  • The .timer file defines when something runs.
  • The .service file defines what runs.
A dark presentation slide titled "SystemD Timers" showing two file icons: one labeled ".timer" with a clock and the caption "Defines when something runs," and one labeled ".service" with a gear. The graphic contrasts timer and service unit files.
Key behavior:
  • When a .timer reaches its scheduled time, systemd activates the associated .service.
  • Timers can be relative (e.g., OnActiveSec), absolute (OnCalendar), or tied to boot/shutdown events.
  • Timers integrate with systemd targets and the systemd journal for consistent logging and control.

​
Where timer units live

Timer unit files can be created or provided by different sources. Use this table to choose the correct location and editing approach.

​
Quick commands

  • List active timers and their next run times:
    • systemctl list-timers
  • Inspect the combined unit contents (vendor file + overrides):
    • systemctl cat <timer-name>
  • Create or edit a drop-in override:
    • systemctl edit <unit>
  • Reload systemd configuration:
    • systemctl daemon-reload
  • Restart or check a unit:
    • systemctl restart <unit>
    • systemctl status <unit>
Example: list timers output and inspecting a timer (these are sample outputs to illustrate the commands):
Inspecting the logrotate.timer combined (vendor file + overrides):
Vendor files (under /usr/lib/systemd/system) may be replaced by package updates. To customize safely, do one of the following:
  • Copy the vendor unit to /etc/systemd/system and edit the copy — this creates a full local unit.
  • Prefer creating a drop-in override using systemctl edit <unit> — this preserves the vendor unit and applies only your changes.
Use systemctl edit <unit> to create a drop-in override file under /etc/systemd/system/<unit>.d/. This preserves the vendor file and keeps your customizations separate and upgrade-safe.
Behavior of drop-ins:
  • Drop-in files live in /etc/systemd/system/<unit>.d/ and are merged on top of vendor files.
  • To replace an existing directive from the vendor file, first clear it by assigning an empty value, then add the new value.
Example: create an override to schedule logrotate.timer to run once on 2026-05-01 at 10:00:00. Contents of the created override file (/etc/systemd/system/logrotate.timer.d/override.conf):
After saving the drop-in, systemctl acknowledges the installation and you can verify the effective configuration with systemctl cat:
Reload systemd and restart the timer so it picks up the new schedule:
This ensures systemd will activate the associated logrotate.service at the updated time.

​
Summary

  • systemd timers are the preferred, systemd-native replacement or complement to cron where you need improved logging, dependency handling, and integration with system state.
  • Always prefer drop-in overrides (via systemctl edit) to preserve vendor files and ensure updates don’t overwrite your changes.
  • Use systemctl list-timers and systemctl cat to inspect timer schedules and effective unit configurations.
Further reading and references: This concludes the demo on managing systemd timers.

Watch Video