Why use a systemd timer instead of cron?

A systemd timer runs your job as a real, supervised unit: its output and exit status land in the journal (journalctl) instead of disappearing or emailing root, you can see the last and next run with systemctl list-timers, it can catch up a missed run after downtime with Persistent=true, and it inherits systemd's resource limits and sandboxing. cron still works fine for simple cases, but timers give you visibility and control that cron does not.

OnCalendar is systemd's schedule syntax, the timer equivalent of a cron expression. It looks like DayOfWeek Year-Month-Day Hour:Minute:Second, with * for any value and step syntax like 0/15 for every 15. The converter translates your cron fields into it; always confirm the result with systemd-analyze calendar, which prints the next times the schedule will fire.

Will the converted schedule be exact?

For common schedules - every N minutes, hourly, daily at a time, weekly on a day - yes. Cron has some quirky cases (notably how day-of-month and day-of-week combine with OR rather than AND) that do not map one-to-one, so for complex expressions the tool gives you the closest OnCalendar and tells you to verify it with systemd-analyze calendar before relying on it.

Free tool · Runs in your browser

Crontab → systemd timer.

cron jobs run in the dark — no logs, no status, no catch-up. Paste a crontab line and get an equivalent systemd service + timer: supervised, logged in the journal, and visible with one command.

Crontab line

—

unit files

install

Out of the dark

A cron job that fails at 3am fails silently — the output goes nowhere you'll look, there's no record it even ran, and if the box was down at 3am the run is simply lost. A systemd timer fixes all three: the run is a unit with its output in the journal, systemctl list-timers shows you the last and next fire, and Persistent=true catches up a run missed during downtime. Same schedule, far more visibility.

That visibility is the small version of a bigger need: knowing your scheduled work actually ran, across every host, and hearing about it when it didn't. Turning “it's in cron somewhere” into something you can see and prove is exactly the operational clarity a control plane provides over the infrastructure you own.

Related free tools

Deploy to your own serverPush-to-deploy, your box systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS Backup script generatorDump, offsite, restore

All free tools →

Scheduled, supervised, visible.

Infraveil runs and watches your scheduled jobs across the hosts you own — so you know what ran, what didn't, and why, with a tamper-evident record instead of a silent cron line.

See how it works

Get the keep-it-running playbook

Jobs, timers, supervision, and visibility for a backend you run yourself. No spam.