systemd Timer Generator
Explain a systemd OnCalendar expression with its next run times, and generate the .timer and .service units to replace a cron job.
Free · No sign-up · Your inputs stay in your browser
Input
Explain OnCalendar and generate a systemd timer
Output
Next runs (UTC)
Normalised
Mon..Fri *-*-* 02:30:00
| Run |
|---|
| Fri 2026-11-06 02:30 |
| Mon 2026-11-09 02:30 |
| Tue 2026-11-10 02:30 |
| Wed 2026-11-11 02:30 |
| Thu 2026-11-12 02:30 |
| Fri 2026-11-13 02:30 |
Timer unit
# /etc/systemd/system/db-backup.timer [Unit] Description=Run db-backup on schedule [Timer] OnCalendar=Mon..Fri *-*-* 02:30:00 Persistent=true RandomizedDelaySec=5m [Install] WantedBy=timers.target
Service unit
# /etc/systemd/system/db-backup.service [Unit] Description=db-backup [Service] Type=oneshot ExecStart=/usr/local/bin/db-backup.sh
Enable with: systemctl daemon-reload && systemctl enable --now db-backup.timer, then systemctl list-timers.
systemd reads the expression as DayOfWeek Year-Month-Day Hour:Minute:Second, with .. for ranges, commas for lists and / for steps; a missing field means 00, not *. Times are in the server's local zone unless the expression ends with a zone such as UTC. systemd-analyze calendar 'expr' prints the normalised form and next run on the machine itself.
Runs in this browser. Nothing you paste is sent to a server.
About this tool
Method, assumptions, practical next steps, and limits.
Timers versus cron
A systemd timer logs every run to the journal, can catch up on runs missed while the machine was off (Persistent=true), spreads load with a random delay, and runs the job with the resource limits and sandboxing of a service unit. The cost is two files instead of one line. The systemd.time manual defines the calendar syntax.
Reading the syntax
The format is DayOfWeek Year-Month-Day Hour:Minute:Second. Ranges use two dots, lists commas and steps a slash; a field that is left out means zero for time, not every value, so *-*-* 02:30 runs once a day.
