A systemd timer schedules tasks on Linux systems. Each timer requires a matching service file that defines the command to execute. Timer units end with .timer and service units end with .service.

Timers integrate with the systemd journal for centralized logging and support dependency management between services.

Types of Systemd Timers

Systemd provides two timer categories.

Monotonic Timers

Monotonic timers activate after a duration relative to a reference point. These timers pause during system suspension.

Keyword Trigger Point
OnBootSec Relative to machine startup
OnActiveSec Relative to timer activation
OnUnitActiveSec Relative to last service completion
OnUnitInactiveSec Relative to last service stop

Realtime Timers

Realtime timers trigger at specific calendar moments. Use the OnCalendar directive to define these timers.

Expression Meaning
hourly Start of each hour
daily Every day at midnight
weekly Every Monday at midnight
Mon..Fri 22:30 Weekdays at 10:30 PM

Create a Service File

Create a service file in /etc/systemd/system/. Example service file named backup.service:

[Unit]
Description=Run backup script

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

The Type=oneshot parameter indicates the service completes a task then exits.

Note: Service files triggered by timers do not require an [Install] section.

Create a Timer File

Timer files define when the service runs. Create a timer file with the same base name as the service.

Monotonic Timer Example

Create backup.timer to run fifteen minutes after boot and repeat weekly:

[Unit]
Description=Backup timer

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w

[Install]
WantedBy=timers.target

Realtime Timer Example

Create a calendar-based timer that runs every Monday:

[Unit]
Description=Weekly backup timer

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target

The Persistent=true option ensures missed executions run after system restart.

Activate the Timer

Place both files in /etc/systemd/system/. Enable and start the timer:

$ sudo systemctl daemon-reload
$ sudo systemctl enable backup.timer
$ sudo systemctl start backup.timer
Tip: Combine enable and start with systemctl enable --now backup.timer.

View Running Timers

Display all active timers:

$ systemctl list-timers

Include inactive timers:

$ systemctl list-timers --all

Check a specific timer:

$ systemctl status backup.timer

OnCalendar Syntax

The OnCalendar directive accepts flexible time specifications. Validate calendar expressions:

$ systemd-analyze calendar "Mon..Fri 08:00"

Complex schedule examples:

OnCalendar=Mon,Wed,Fri 10:00
OnCalendar=*-*-* 06,12,18:00:00
OnCalendar=Sat *-*-1..7 15:00:00

Useful Timer Options

Persistent

Add Persistent=true to run missed executions after system downtime. The timer triggers immediately when the system restarts.

AccuracySec

Control execution precision with AccuracySec. Default is one minute. Set AccuracySec=1us for microsecond accuracy:

[Timer]
OnCalendar=daily
AccuracySec=1us
Warning: Lower accuracy values increase power consumption. Use precise timing only when necessary.

RandomizedDelaySec

Prevent simultaneous timer execution with random delays:

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h

The timer executes at a random time within one hour of the scheduled time.

Transient Timers

Create temporary timers without unit files using systemd-run. Run a command after thirty seconds:

# systemd-run --on-active=30 /bin/touch /tmp/testfile

Create a calendar-based transient timer:

# systemd-run --on-calendar="Mon 14:00" /usr/bin/cleanup.sh

Stop a running transient timer:

$ systemctl stop run-unit-id.timer

Advantages Over Cron

Systemd timers provide several benefits:

  • Jobs log directly to the systemd journal
  • Services can depend on other systemd units
  • Resource control through cgroups
  • Better error handling and failure notifications
  • Missed jobs run automatically with Persistent=true

View logs with journalctl -u service-name.

FAQs

Systemd timers integrate with the journal for centralized logging. They support dependencies between services and provide resource control. Cron requires manual logging configuration and lacks service dependency management.

No. Each timer file triggers one service. Create separate timer units for each service. Use the Unit= directive to specify a differently-named service if needed.

Set Persistent=true in the timer configuration. The timer triggers immediately when the system restarts if it missed one or more scheduled executions during downtime.

Manually trigger the associated service with systemctl start service-name.service. This executes the service immediately without affecting the timer schedule. Check logs with journalctl.

Place custom timer and service files in /etc/systemd/system/. System-provided units reside in /usr/lib/systemd/system/. User-specific timers go in ~/.config/systemd/user/.

Willie has over 15 years of experience in Linux system administration and DevOps. After managing infrastructure for startups and enterprises alike, he founded Command Linux to share the practical knowledge he wished he had when starting out. He oversees content strategy and contributes guides on server management, automation, and security.