Move a crontab line to a systemd timer.

It takes a single crontab line — the five time fields plus the command — and generates an equivalent systemd setup: a .timer unit with an OnCalendar= expression that matches your schedule, and a .service unit that runs your command. It also lists migration notes that flag anything systemd handles differently, like the implicit working directory or environment. Everything is computed in your browser.

No. The converter runs 100% client-side. Your cron line and command are parsed and translated in your browser tab — nothing is uploaded to a server, and there is no account or signup. It is safe to paste internal commands and paths.

A crontab field set is rewritten into systemd's OnCalendar= calendar syntax — for example “0 3 * * *” becomes “*-*-* 03:00:00” (daily at 03:00). Lists, ranges and step values map to their OnCalendar equivalents, and common @macros like @daily and @hourly map to their canonical timer forms. After installing the timer you can confirm the next runs with “systemctl list-timers”.

Timers give you structured logging through the journal (journalctl -u your.service), dependency ordering, resource limits, automatic retry and accurate-vs-monotonic scheduling, plus Persistent=true so a missed run can fire on next boot. They are the native scheduling primitive on modern systemd Linux distributions, where the per-user crond is often not even installed.

A few cron behaviours have no direct OnCalendar= analogue and surface as migration notes instead — non-standard or vendor cron extensions, MAILTO email-on-output (use journald or an OnFailure= handler), and per-line environment assignments (move these to Environment= or an EnvironmentFile= in the .service). The converter flags these so nothing silently changes meaning.

No. This is an independent, community utility and is not affiliated with or endorsed by the systemd project or any cron implementation. It models the standard crontab and systemd unit formats for familiarity and names them only to describe what it converts.

@reboot has no OnCalendar= equivalent and maps to OnBootSec=1min in the [Timer] section, so the job fires once shortly after each boot. @hourly expands to OnCalendar=*-*-* *:00:00, @daily to OnCalendar=*-*-* 00:00:00, @weekly to OnCalendar=Sun *-*-* 00:00:00, @monthly to OnCalendar=*-*-01 00:00:00, and @yearly to OnCalendar=*-01-01 00:00:00. The converter handles all of these automatically and notes the @reboot special case.

Add Persistent=true to the [Timer] section alongside your OnCalendar= line. systemd records the last trigger time on disk and, if the scheduled time passed while the machine was down, runs the job immediately on the next boot. The converter always includes Persistent=true in the generated .timer unit so this behaviour is on by default.

For system-wide jobs place both units in /etc/systemd/system/, then run sudo systemctl daemon-reload and sudo systemctl enable --now yourjob.timer. Enable the .timer unit — not the .service directly, since the timer is what controls the schedule. For per-user jobs place them in ~/.config/systemd/user/ and use systemctl --user enable --now yourjob.timer instead.

Run systemd-analyze calendar “<expression>” to validate the syntax and see when the expression will next elapse — for example systemd-analyze calendar “*-*-* 03:00:00”. Once the timer is installed, systemctl list-timers shows every active timer with its last and next run times, and journalctl -u yourjob.service streams the job output.