systemd timer generator
Create the timer and service files for a scheduled job, validated, with hardening options and the install commands.
A cron job, the systemd way
For anything that runs unattended on a Linux server, a systemd timer has real advantages over a crontab line: output goes to the journal (journalctl -u name), the job runs as a defined user with a defined environment, you can see the next and last run with systemctl list-timers, missed runs can be caught up, and hardening options sandbox the process. The price is two small files instead of one line.
Fill in the command, the user and working directory, and the schedule in OnCalendar syntax (use the cron converter on this site if you start from a cron expression). The generator writes the .service file (a oneshot unit, with optional environment variables and security hardening) and the .timer file, plus the exact commands to install and check them. The schedule is validated before you copy anything.
What the options do
Type=oneshot: the unit is "active" while the command runs and systemd records its exit status.NoNewPrivileges,PrivateTmp,ProtectSystem=strict,ProtectHome: the job gets a read-only file system view except for the paths you allow. Loosen them if the job needs more.AccuracySec: timers fire within a one-minute window by default to save power; set it lower only if you need precision.Persistent=true: catch up after downtime.
Use ExecStart with an absolute path: systemd does not search the shell's PATH the way cron's shell does. Everything is generated in your browser.
Frequently asked questions
Why does a timer need two files?
The .timer unit holds the schedule and the .service unit holds the command. When the timer elapses it starts the service with the same name. You enable the timer, not the service.
What does Persistent=true do?
systemd remembers when the timer last ran. If the machine was off at a scheduled time, the missed run is triggered once as soon as the timer is active again. Cron has no equivalent, which is why laptops and VMs lose jobs under cron.
What is RandomizedDelaySec for?
It delays each start by a random time up to the given value, so a fleet of machines does not all call the same service at the same second.
What happens if a run is still going when the next one is due?
The timer does not start a second copy while the service is active; the activation is skipped. Cron would start another process. To enforce a single instance under cron you need a lock.