Systemd Timer Generator

Systemd Timers vs Cron Jobs — Which Should You Use?

Systemd timers are the standard utility for running scheduled recurring tasks on modern Linux distributions including Ubuntu 20.04+, Debian 11+, CentOS 8+, RHEL 9, Fedora, and Arch Linux. While crontab has been the default scheduler for decades, it has significant operational limitations compared to systemd's integrated service management.

• Logging: Cron runs jobs silently — output is lost unless you redirect it manually. Systemd timers capture all stdout and stderr output automatically via journald. View logs instantly with journalctl -u yourjob.service.
• Missed runs: If a server is offline when a cron job triggers, that run is skipped silently. With Persistent=true, systemd will execute the job immediately after the next reboot to catch up.
• Resource controls: Cron has no built-in CPU or memory limits. Systemd service units support CPUQuota=, MemoryMax=, and IOWeight= to prevent any single scheduled job from impacting system performance.
• Randomized start delays: RandomizedDelaySec=300 tells systemd to start the job at a random time within a 5-minute window of the scheduled time. This is critical in cloud environments to prevent all instances in a cluster from hammering a database or API endpoint simultaneously.
• Dependencies: Systemd units support explicit dependency declarations via After=network.target, Requires=, and Wants=, ensuring that jobs don't run before required services are ready.

Understanding the OnCalendar Format

The OnCalendar= directive uses systemd's own calendar event syntax, which is more readable than traditional 5-field cron expressions:

• *-*-* 00:00:00 — Every day at midnight (equivalent to cron 0 0 * * *)
• *-*-* *:00:00 — Every hour at the top of the hour (0 * * * *)
• Mon *-*-* 00:00:00 — Every Monday at midnight (0 0 * * 1)
• *-*-01 00:00:00 — First of every month at midnight (0 0 1 * *)
• Mon,Wed,Fri 08:30:00 — Monday, Wednesday, Friday at 8:30 AM
• *-*-* 02:00:00 — Daily at 2:00 AM

You can validate any OnCalendar= expression by running systemd-analyze calendar "Mon *-*-* 10:00:00", which shows the next 10 trigger times.

The .timer and .service File Structure

Every systemd timer consists of two paired files that must share the same base name (e.g., cleanup-logs.timer and cleanup-logs.service):

• The .timer file contains the [Timer] section defining when the job runs — including OnCalendar=, RandomizedDelaySec=, and Persistent=. It must also have an [Install] section with WantedBy=timers.target for it to be activated on boot.
• The .service file describes what runs — the executable command via ExecStart=, the system user via User=, and service type (typically Type=oneshot for scripts that run and exit).

Debugging Scheduled Jobs with Systemd

One of the most compelling arguments for switching from cron is the superior debugging experience. When a systemd service executes, all terminal output is captured by journald. You can view full logs including timestamps, exit codes, and error messages using:

• journalctl -u myjob.service — View all past execution logs for the service.
• journalctl -u myjob.service -f — Follow live output during an execution.
• systemctl list-timers --all — View all timers, their last trigger time, and next scheduled run.
• systemctl status myjob.timer — Check if the timer is active and when it will next fire.

Privacy — 100% Client-Side Generation

The entire .timer and .service file generation runs client-side in your browser. None of your service names, execution commands, user names, or scheduling parameters are transmitted over the network. You can verify this by checking the Browser DevTools Network tab — zero outbound requests are made during file generation.