How to Create a systemd Timer on Linux: 7 Safe Steps

What you will build

The goal is modest: a demo command prints a timestamp. A .service unit runs the command; a .timer unit starts the service every five minutes. This systemd timer is intentionally simple, so each stage is easy to inspect. You will also start the service manually, so you can verify success without waiting for a scheduled run.

This is a hypothetical training exercise, not a benchmark or a backup recipe. It is designed for an Ubuntu, Debian, or similar Linux server using systemd as PID 1. Use a disposable VM or a noncritical test host; you need sudo access. The commands below change local system configuration, so read the cleanup step before starting.

Confirm that systemd is installed and that the unprivileged nobody account exists. Check that the three example paths are unused before creating anything. A test command is silent when it succeeds; if a path already exists, stop and use a different lab name rather than overwriting someone else’s files.

systemctl --version | head -n 1
id nobody
if [ -e /usr/local/bin/sa-timer-demo.sh ] ||
   [ -e /etc/systemd/system/sa-timer-demo.service ] ||
   [ -e /etc/systemd/system/sa-timer-demo.timer ]; then
  printf 'Stop: a demo path already exists.\n'
else
  printf 'All demo paths are available.\n'
fi

Rather than modifying logs, databases, or user files, the demo prints one line containing the time. This makes the job visible in the journal without needing a writable directory. A systemd timer can manage a much more complex script later, but the basic setup is the same.

sudo tee /usr/local/bin/sa-timer-demo.sh >/dev/null <<'EOF'
#!/bin/sh
set -eu
printf 'sa-timer-demo: executed at %s\n' "$(/usr/bin/date --iso-8601=seconds)"
EOF
sudo chmod 0755 /usr/local/bin/sa-timer-demo.sh
/usr/local/bin/sa-timer-demo.sh

The final command runs the script once in your current terminal. If that test fails, fix the script first; a timer cannot repair a broken program. Its output should resemble sa-timer-demo: executed at 2026-10-16T12:15:00+00:00, but your actual time and time zone will differ.

The service defines what systemd will run. For this single action, Type=oneshot is a good fit: systemd waits for the script to finish instead of expecting a long-running daemon.

sudo tee /etc/systemd/system/sa-timer-demo.service >/dev/null <<'EOF'
[Unit]
Description=Servers Academy demonstration task

[Service]
Type=oneshot
User=nobody
ExecStart=/usr/local/bin/sa-timer-demo.sh
StandardOutput=journal
StandardError=journal
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
EOF

A successfully completed oneshot service will normally return to inactive (dead). That is not evidence of failure. Its exit result and journal entries tell the story. For background on unit structure, see how to create a systemd service.

Now define when the service runs. This is the systemd timer unit, separate from the service it will activate. The expression below means minute 00, 05, 10, 15 and so on, every hour. Five minutes is useful for a short lab; you would probably choose a less frequent schedule for a real maintenance job.

sudo tee /etc/systemd/system/sa-timer-demo.timer >/dev/null <<'EOF'
[Unit]
Description=Run the Servers Academy demo every five minutes

[Timer]
OnCalendar=*-*-* *:00/5:00
AccuracySec=1min
Persistent=false
Unit=sa-timer-demo.service

[Install]
WantedBy=timers.target
EOF

Setting AccuracySec=1min allows systemd to coalesce timer events within roughly the following minute rather than promise execution on the exact second. The local system clock and time zone affect calendar calculations; review them with timedatectl if your output seems unexpected.

Before enabling the schedule, ask systemd to parse the time expression and show its next occurrences. Then verify the unit definitions, reload the manager and start the service once manually. This isolates script errors from timer errors.

systemd-analyze calendar --iterations=3 '*-*-* *:00/5:00'
sudo systemd-analyze verify /etc/systemd/system/sa-timer-demo.service /etc/systemd/system/sa-timer-demo.timer
sudo systemctl daemon-reload
sudo systemctl start sa-timer-demo.service
sudo journalctl -u sa-timer-demo.service -n 12 --no-pager

Enable the timer so it starts again after boot, and start it now. The systemd timer will take care of activating its matching service when the configured time arrives.

sudo systemctl enable --now sa-timer-demo.timer
systemctl is-enabled sa-timer-demo.timer
systemctl is-active sa-timer-demo.timer
systemctl list-timers --all sa-timer-demo.timer
systemctl status sa-timer-demo.timer --no-pager

is-enabled answers whether the timer is configured to start automatically; is-active tells you if it is currently running. list-timers shows the next and previous trigger times when available. None of these, by itself, proves the script finished successfully: use the service journal for that.

When you have seen the scheduled run—or checked a manual run and the next planned trigger—remove the demonstration. These commands operate only on the three paths introduced in this systemd timer tutorial. Read each path before running them.

sudo systemctl disable --now sa-timer-demo.timer
sudo rm -- /etc/systemd/system/sa-timer-demo.timer
sudo rm -- /etc/systemd/system/sa-timer-demo.service
sudo rm -- /usr/local/bin/sa-timer-demo.sh
sudo systemctl daemon-reload

For a real job, choose the required account and filesystem permissions deliberately, use absolute paths, test manually, and decide whether catch-up execution is safe. Backups, in particular, require verifying actual restore capability; seeing a timer fire is not a backup test.

Which systemd timer settings should you use?

A useful systemd timer starts with the requirements of the job, not a collection of copied directives. Do not combine settings just because they look useful.

If you already use cron, read Cron vs systemd Timers before migrating. The two tools have different operational tradeoffs; one is not universally better.

When the timer appears to work but nothing happens

For detailed log-reading techniques, see journalctl Explained. The next lesson in this mini-course will focus on diagnosing missed runs, failed units and recurring scheduling problems.

Quick knowledge check