DevOps

systemd Timer Generator

Generate a matching systemd timer and service pair with OnCalendar expressions, randomised delay, persistence across reboots and the correct dependency wiring.

Last reviewed by the Radiatus Cloud team

Units appear here.

Want this automated for your stack?

We build CI/CD, Kubernetes & IaC pipelines that scale.

Talk to an engineer

What a timer gives you that cron does not

A systemd timer runs a service unit on a schedule, which means the job inherits everything a unit can do: structured logging in the journal, dependency ordering, resource limits, sandboxing, and a record of whether the last run succeeded. cron gives you a line in a file and an email if it fails, assuming mail works, which on a modern server it usually does not. Timers also survive the machine being off: Persistent=true runs a missed job at the next boot, which cron cannot do at all.

OnCalendar is not cron syntax

The format is a date and time specification rather than five fields, so it reads as Mon..Fri *-*-* 03:00:00 rather than 0 3 * * 1-5. It is more expressive: sub second precision, ranges anywhere, and shortcuts such as daily, weekly and quarterly. The systemd-analyze calendar command validates an expression and prints the next elapse, which is the fastest way to check a schedule before deploying it.

RandomizedDelaySec prevents the thundering herd

A fleet of two hundred machines all running a job at exactly 03:00 produces a spike that saturates whatever the job talks to. Adding a randomised delay spreads the start times across a window, and because the offset is derived from the machine identity it stays consistent across runs rather than moving each time. This one line is the difference between a backup job that works and one that overwhelms the backup target every night.

Related tools

Frequently Asked Questions

How is OnCalendar different from cron?

It is a calendar specification rather than five positional fields, written as DayOfWeek Year-Month-Day Hour:Minute:Second. It supports ranges and steps anywhere, sub second precision, and named shortcuts. Validate any expression with systemd-analyze calendar before deploying.

What does Persistent=true do?

It records when the timer last ran and triggers immediately at boot if the scheduled time was missed while the machine was off. cron has no equivalent, which is why a daily cron job on a laptop simply never runs.

Should the service unit be enabled?

No. Enable the timer, not the service. The timer pulls in the service when it fires. Enabling both makes the service run at boot as well as on the schedule, which is a common and confusing mistake.

How do I see when a timer will next run?

systemctl list-timers shows every timer with its next and last elapse. For an expression you have not deployed yet, systemd-analyze calendar "Mon *-*-* 03:00" prints the next several occurrences.

When is cron still the right choice?

On a system without systemd, or when the job must run under a user crontab that other tooling manages. For anything on a systemd host, timers give better logging, dependency handling and failure visibility for the same effort.

Privacy & Security

Everything runs in your browser; nothing is uploaded.

Data: None
Client-side-Side
Active
v1.0

How to Use

Choose a schedule and command to generate both the .timer and .service unit files.

Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.