Where do the files go and how do I enable them?

System units go in /etc/systemd/system/. Run sudo systemctl daemon-reload, then sudo systemctl enable --now name.service to start it now and at every boot. Check it with systemctl status name and follow logs with journalctl -u name -f. User units go in ~/.config/systemd/user/ with --user on every command, plus loginctl enable-linger so they keep running after you log out.

How does a cron expression map to OnCalendar?

cron’s “minute hour day month weekday” maps to OnCalendar’s “weekday year-month-day hour:minute:second”, so 0 9 * * 1-5 becomes Mon..Fri *-*-* 09:00:00 and */15 * * * * becomes *:0/15. When cron restricts both the day of month and the weekday it means either one matches, while systemd requires both, so the tool emits two OnCalendar lines. Times use the server’s local time zone unless you append UTC.

Why use a timer instead of crontab?

Every run is logged in the journal (journalctl -u service), systemctl list-timers shows the next run, Persistent=true catches up on runs missed while the machine was off, and RandomizedDelaySec keeps a fleet from running at once. The job is an ordinary service, so it can reuse dependencies, resource limits and hardening, and a new run never overlaps one that is still going.

Can the hardening options break my program?

They can, so only options that almost never interfere are on by default: NoNewPrivileges, PrivateTmp, ProtectSystem=full and ProtectHome. ProtectSystem=strict needs ReadWritePaths for directories the program writes; MemoryDenyWriteExecute breaks JITs such as Node.js and Java; RestrictNamespaces does not suit container tools. Run systemd-analyze security name.service to see the score and test each change.

🐧

🐧systemd Service & Timer Generator - Cron to OnCalendar

Need a program to start at boot on Linux, restart when it crashes, or replace a crontab entry with a systemd timer? This tool generates unit files you can drop into /etc/systemd/system. The .service form covers the description, Type (simple, exec, forking, oneshot, notify, idle), ExecStart, ExecStartPre, ExecReload and ExecStop, User and Group or DynamicUser, WorkingDirectory, Environment (quoted automatically when values contain spaces) and EnvironmentFile, Restart policy and RestartSec, start rate limits, After/Wants/Requires and WantedBy, logging, open-file and memory/CPU limits, and a set of hardening options (NoNewPrivileges, ProtectSystem, ProtectHome, PrivateTmp, PrivateDevices, kernel protection, RestrictSUIDSGID, MemoryDenyWriteExecute, SystemCallFilter, binding port 80 without root and more), each with an explanatory comment. For .timer files you can write an OnCalendar expression, convert a cron expression (day-of-month plus weekday becomes two lines because the semantics differ) or create a monotonic “every N minutes/hours” timer, with the normalized form and the next elapse times shown live; Persistent, randomized delay, accuracy and wake-up are supported too. A third tab explains a pasted unit file line by line and checks for wrong sections, invalid booleans and time spans, relative command paths, pipes and redirects, Environment quoting, a missing ExecStart, oneshot with Restart, network-online.target misuse, a missing [Install] section and other common mistakes. Install commands with daemon-reload, enable --now and journalctl are included, for system and --user units.

Free · No sign-up · Runs in your browserLast updated: 2026-10-26

Loading tool...

How to use systemd Unit Generator

1On the .service tab, enter the unit name, command, user and restart policy, and tick the hardening options you want
2For scheduled jobs, open the .timer tab and enter an OnCalendar expression, a cron expression or an interval, then check the next run times
3Download the .service and .timer files, copy them to the server and run the systemctl enable --now commands shown

FAQ

Where do the files go and how do I enable them?: System units go in /etc/systemd/system/. Run sudo systemctl daemon-reload, then sudo systemctl enable --now name.service to start it now and at every boot. Check it with systemctl status name and follow logs with journalctl -u name -f. User units go in ~/.config/systemd/user/ with --user on every command, plus loginctl enable-linger so they keep running after you log out.
How does a cron expression map to OnCalendar?: cron’s “minute hour day month weekday” maps to OnCalendar’s “weekday year-month-day hour:minute:second”, so 0 9 * * 1-5 becomes Mon..Fri *-*-* 09:00:00 and */15 * * * * becomes *:0/15. When cron restricts both the day of month and the weekday it means either one matches, while systemd requires both, so the tool emits two OnCalendar lines. Times use the server’s local time zone unless you append UTC.
Why use a timer instead of crontab?: Every run is logged in the journal (journalctl -u service), systemctl list-timers shows the next run, Persistent=true catches up on runs missed while the machine was off, and RandomizedDelaySec keeps a fleet from running at once. The job is an ordinary service, so it can reuse dependencies, resource limits and hardening, and a new run never overlaps one that is still going.
Can the hardening options break my program?: They can, so only options that almost never interfere are on by default: NoNewPrivileges, PrivateTmp, ProtectSystem=full and ProtectHome. ProtectSystem=strict needs ReadWritePaths for directories the program writes; MemoryDenyWriteExecute breaks JITs such as Node.js and Java; RestrictNamespaces does not suit container tools. Run systemd-analyze security name.service to see the score and test each change.