Cron to systemd Timer Converter
Paste a cron expression and get matching .service and .timer unit files.
Client-side only — nothing leaves your browser
Every 15 minutes
Used as myjob.service and myjob.timer
Leave blank to inherit systemd's default
Use an absolute path. systemd does not source your shell PATH.
[Unit]
Description=Run myjob
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
[Unit]
Description=Timer for myjob
[Timer]
OnCalendar=*-*-* *:00/15:00
Persistent=true
Unit=myjob.service
[Install]
WantedBy=timers.target
# Save the files (system-wide)
sudo nano /etc/systemd/system/myjob.service
sudo nano /etc/systemd/system/myjob.timer
# Reload systemd, then enable and start the timer
sudo systemctl daemon-reload
sudo systemctl enable --now myjob.timer
# Verify
systemctl list-timers myjob.timer
systemctl status myjob.timerWhat is a systemd Timer?
A systemd timer is a unit file that triggers another systemd unit (usually a service) on a schedule. Timers are systemd's modern replacement for cron jobs on Linux distributions that use systemd as their init system — including Ubuntu, Debian, Fedora, Arch, RHEL, CentOS Stream, and most container base images. A timer requires two files: a .timer unit that defines when to run, and a matching .service unit that defines what to run.
Cron to OnCalendar Mapping
The OnCalendar= directive uses a DOW YYYY-MM-DD HH:MM:SS format. Here is how common cron expressions translate:
| Cron | OnCalendar | Meaning |
|---|---|---|
| * * * * * | *-*-* *:*:00 | Every minute |
| */5 * * * * | *-*-* *:0/5:00 | Every 5 minutes |
| 0 * * * * | hourly | Every hour at :00 |
| 0 0 * * * | daily | Every day at midnight |
| 0 3 * * * | *-*-* 03:00:00 | Every day at 3:00 AM |
| 0 9 * * 1-5 | Mon..Fri *-*-* 09:00:00 | Weekdays at 9:00 AM |
| 0 0 * * 0,6 | Sat,Sun *-*-* 00:00:00 | Weekends at midnight |
| 0 0 1 * * | monthly | 1st of every month at midnight |
| @reboot | OnBootSec=1min | After boot completes |
| @yearly | yearly | January 1 at midnight |
Why use systemd Timers Instead of Cron?
| Capability | cron | systemd timer |
|---|---|---|
| Logs in journal | No (separate cron.log) | Yes (journalctl) |
| Catch up on missed runs | No (anacron only) | Yes (Persistent=true) |
| Random delay (jitter) | No | Yes (RandomizedDelaySec) |
| Resource limits | No | Yes (cgroups) |
| Dependencies on other units | No | Yes (After=, Requires=) |
| Granularity | 1 minute | 1 microsecond |
Useful systemd Timer Commands
| Command | What it does |
|---|---|
| systemctl list-timers | Show all active timers and their next run times |
| systemctl list-timers --all | Include inactive timers as well |
| systemctl status myjob.timer | Inspect a specific timer |
| systemctl start myjob.service | Trigger the job manually right now |
| journalctl -u myjob.service | View output and logs from past runs |
| systemd-analyze calendar "Mon..Fri 09:00" | Validate an OnCalendar expression and preview next runs |
Frequently Asked Questions
What is a systemd timer?
A systemd timer is a unit file (.timer) that schedules another systemd unit, almost always a matching .service file. The timer says when to run; the service says what to run. Timers replace cron on systemd-based Linux distributions (Ubuntu, Debian, Fedora, Arch, RHEL, etc.) and integrate with the rest of systemd: logs go to the journal, you can set dependencies on other units with After= and Requires=, and you can apply resource limits via cgroups. There are two main triggers: OnCalendar= for wall-clock schedules (the cron equivalent) and monotonic timers like OnBootSec= and OnUnitActiveSec= that count from a reference event.
Should I use systemd timers or cron?
Use systemd timers for anything new on a systemd-based system. They log to journalctl alongside everything else, support Persistent=true so missed runs (e.g. while the laptop was asleep) are caught up on next boot, allow RandomizedDelaySec to spread load across a fleet, run inside cgroups for resource isolation, and can declare dependencies on other units. Cron is still fine for quick one-liners on minimal containers without systemd, or when portability across non-Linux Unix systems matters. For everything else, timers are the modern default and most distributions ship core maintenance tasks (logrotate, fstrim, apt updates) as timers rather than cron jobs.
Where are systemd timer files stored?
It depends on scope. System-wide timers maintained by you live in /etc/systemd/system/, which is what this tool's install commands use. Distribution-packaged timers live in /usr/lib/systemd/system/ (or /lib/systemd/system/ on Debian) and should not be edited directly — override them with a drop-in at /etc/systemd/system/<unit>.d/override.conf instead. User timers (no root needed) live in ~/.config/systemd/user/ and are managed with systemctl --user. After adding or changing any unit file you must run systemctl daemon-reload before enabling it.
What does Persistent=true do in a systemd timer?
Persistent=true tells systemd to remember the last time the timer fired and to run the service immediately on next boot if a scheduled run was missed while the system was off. Without it, an OnCalendar=daily timer on a laptop that was asleep at 03:00 would simply skip that day. Persistent=true is the closest equivalent to anacron's catch-up behavior, which standard cron does not provide. The state is stored as a timestamp file under /var/lib/systemd/timers/ (or the user equivalent), so the timer must run at least once before the persistence kicks in.
Why is my systemd timer not triggering?
The most common causes: (1) you forgot systemctl daemon-reload after editing the unit, (2) you enabled the .service instead of the .timer — only the timer should be enabled, (3) the OnCalendar expression is invalid, which you can verify with systemd-analyze calendar "<your-expr>" (this is also where the "failed to parse calendar specification" error comes from), (4) the service itself is failing on first run — check journalctl -u <name>.service, (5) the command in ExecStart= is not an absolute path or relies on shell features like pipes, which require wrapping in /bin/sh -c. Check systemctl list-timers to see when (or whether) the timer plans to fire next.
Related Tools
Need to manage SSH connections?
SSH Workbench lets you connect, browse files, and manage servers visually.
Try SSH Workbench Free