How to Use the Crontab to systemd Timer Converter Prompt to Move Cron Jobs Without Breaking Them
Move a server's cron jobs to systemd timers without breaking them: translate each crontab line to an OnCalendar expression you can verify, write the matching oneshot service with the right user, working directory, and environment, add catch up for missed runs, sandbox the job, replace MAILTO with an OnFailure alert, and check runs with systemctl and journalctl.

systemd timers give you logs in the journal, catch up runs after downtime, no overlapping jobs, and sandboxing options cron never had. The move looks simple until a script that ran fine under cron fails because its environment changed, or a timer is written and never enabled. The Crontab to systemd Timer Converter: OnCalendar Expressions, Oneshot Service Units with User and EnvironmentFile, Persistent Catch Up, Sandboxing Options, OnFailure Alerts, and journalctl Checks prompt translates each crontab line, writes the service and timer units, adds failure alerts, and walks through a cutover that keeps cron in place until the timer has proven itself.
What the prompt produces
- A translation table from each crontab line to an OnCalendar expression, with the command to verify the next run times.
- A oneshot service unit per job with the right user, group, working directory, and environment.
- A matching timer unit with catch up, randomized delay, and accuracy settings where they help.
- Sandboxing options sized to what each job writes.
- Failure alerts that replace MAILTO with an OnFailure unit.
- A cutover plan from verify and enable through checking runs in the journal.
- Timezone handling when a job must follow a zone other than the server's.
How to fill the inputs
CrontabLines should be pasted exactly, along with which user's crontab or cron.d file they came from. The original owner decides the User setting.
JobBehavior describes what each script does, what it writes to, and how long it runs. This decides which directories need write access and whether overlap is a risk.
JobEnv lists PATH additions, variables, secrets files, and the working directory the scripts expect.
SystemdVersion comes from systemctl --version. Some features, like a timezone inside OnCalendar, depend on it.
Alerting says how failures are reported today.
TimeZone notes the server zone and any job that must run on another zone's clock.
Reading the example output
The example converts three jobs from a deploy user's crontab on Ubuntu:
- Each schedule is translated and verified. Every fifteen minutes becomes a repeating expression, the nightly backup becomes a daily time, and the Monday report becomes a weekday expression.
- Secrets move out of .bashrc into an environment file readable only by root and the service group. Cron never read .bashrc anyway, so this also removes a hidden dependency.
- Units are complete and readable, with absolute paths and a write path for only the directory each job needs.
- Overlap is handled by systemd itself. A oneshot service will not start again while it is still running, which replaces a lock wrapper.
- The weekly report keeps New York time with a timezone in the expression, so it follows daylight saving while the server stays on UTC.
- MAILTO becomes OnFailure, sending the last journal lines for the failed unit.
- Cron lines are commented out only after a manual run succeeds, then deleted after a week of clean runs.
Tips for better results
- Run each service by hand with systemctl start before enabling its timer.
- Use systemd-analyze calendar to check every expression. It prints the next run times.
- Add sandboxing settings one at a time and run the job after each one.
- Let output go to the journal instead of redirecting to log files, then read it with journalctl.
- Use Persistent for jobs that must not be skipped after a reboot, like backups.
Mistakes to avoid
- Do not enable the service units. Enable the timers.
- Do not put secret values directly in unit files.
- Do not delete the crontab lines before the timers have run successfully.
- Do not assume the job's PATH matches your login shell. Set it explicitly.
Who it is for
Linux administrators modernizing older servers, developers who inherited a crontab full of scripts, DevOps engineers standardizing job scheduling, and anyone who wants failed jobs to show up somewhere other than an unread mailbox.
Related PromptDig links
Open the Crontab to systemd Timer Converter: OnCalendar Expressions, Oneshot Service Units with User and EnvironmentFile, Persistent Catch Up, Sandboxing Options, OnFailure Alerts, and journalctl Checks prompt and paste your crontab. For more coding and operations prompts, Browse more prompts. If you have a Linux or DevOps prompt that works, Share a prompt.