systemd Timer Generator

systemd timer generator - a .timer file with an OnCalendar schedule

The systemd timer generator builds a ready .timer file: a [Timer] section with an OnCalendar schedule, an optional Persistent=true and RandomizedDelaySec, a link to the .service unit of the same name, and an [Install] section with WantedBy=timers.target. Type a name and schedule, then copy the result into /etc/systemd/system/.

A timer is only a schedule - the service does the work

The key point: the .timer file itself runs nothing. A timer is only a clock that activates a .service unit at the right moment. By default systemd looks for a service with the same name as the timer - if you have backup.timer, a backup.service must exist. The generator makes that link explicit with a Unit=name.service line. Without a .service file, systemctl enable --now backup.timer enables the clock, but at the scheduled time systemd finds no service and logs an error. You can start the service by hand (systemctl start backup.service) to test it first.

Anatomy of a .timer file

OnCalendar syntax - how to write a schedule

The OnCalendar value takes two forms. Named shortcuts: daily, hourly, weekly (Monday at midnight), monthly (first day of the month). The calendar form follows DayOfWeek Year-Month-Day Hour:Minute:Second, where * means "every". Examples: *-*-* 02:00:00 is every day at 02:00, Mon *-*-* 08:00:00 is Mondays at 08:00, and *-*-01 00:00:00 is the first day of each month. Check any expression without deploying by running systemd-analyze calendar "Mon *-*-* 08:00:00". Beyond OnCalendar there are relative triggers OnBootSec= and OnUnitActiveSec=; you add those by hand in the [Timer] section.

Persistent and RandomizedDelaySec - two options that matter

RandomizedDelaySec adds a random delay within the given range (for example 5m, 1h). It helps when many servers fire the same job at once and you do not want them all hitting one resource at the same time.

How to use the generator

1. Enter the timer name without an extension (for example backup) - it produces backup.timer and links to backup.service.
2. Provide a description and an OnCalendar schedule; if needed set RandomizedDelaySec and tick Persistent.
3. Click Generate timer and copy the result into /etc/systemd/system/backup.timer.
4. Create the matching backup.service with a [Service] section and an ExecStart= - without it the timer has nothing to run.
5. Run systemctl daemon-reload, systemctl enable --now backup.timer, and check the schedule with systemctl list-timers.

systemd timers are the modern successor to cron. If you compare the two approaches, the crontab generator helps. A job that runs in a container gets its image from the Dockerfile generator, and local shortcuts belong in the Makefile generator. When tidying a repository the .dockerignore file generator is handy, and for publishing on Apache so is the .htaccess file generator.

A systemd timer or cron?

Cron is simpler in one line, but a systemd timer wins on reliability. Job logs go to journald (journalctl -u backup.service), so you see output and errors without your own redirection. A timer respects dependencies between units, resource limits from the [Service] section and can catch up on missed runs. Cron stays silent until you configure MAILTO.

What this tool does not do

The generator produces only the .timer file. You write the matching .service with ExecStart= separately - without it the timer is a clock with no alarm. It also does not handle OnBootSec/OnUnitActiveSec triggers or several OnCalendar entries; those you add by hand.

Frequently asked questions