Switch from Cron Jobs to systemd Timers

Your cron job ran at 2 AM, but the server was rebooted at 1:59 AM for a kernel update. Nothing ran. No alert. No log. You find out three days later when a backup directory is suspiciously empty. If that sounds familiar, you've already met the exact problem systemd timers solve.

I've watched this exact scenario play out on production RHEL and Ubuntu servers more times than I'd like to admit. The fix isn't complicated once you know the tool. Systemd timers give you proper logging, missed-run recovery, dependency management, and better schedule control — without needing to install anything extra on modern Linux systems.

This guide covers everything from writing your first timer pair to converting real cron jobs, with distro-specific notes for Ubuntu 24.04 and Rocky Linux 9 / RHEL 9.

Examples

Think of a systemd timer as a two-part replacement for a cron entry. Where cron mashes the "what to run" and "when to run it" into a single line, systemd splits those into two separate unit files: a .service file that defines the task, and a .timer file that defines the schedule.

The .service file is the same kind you'd use for a long-running daemon, just set to Type=oneshot so systemd knows the task runs once and exits. The .timer file points at that service and tells systemd when to fire it.

Both files live in /etc/systemd/system/ and share the same base name. So backup.timer automatically pairs with backup.service unless you explicitly specify otherwise. That naming convention is worth remembering because it avoids a lot of confusion when you're managing multiple timers.

From a practical workflow perspective: you write a script, wrap it in a service unit, schedule it with a timer unit, enable the timer, and you're done. The whole thing integrates natively with journald, so every run produces a log entry you can pull up with journalctl — no mailbox required.

A minimal systemd timer consists of two files. Here's the basic structure of each:

The service file — defines what runs:

The timer file — defines when it runs:

Breaking down the key fields: Type=oneshot tells systemd this service runs once and exits — not a persistent daemon. OnCalendar takes a date-time expression in the format YYYY-MM-DD HH:MM:SS, using * as a wildcard. Persistent=true is the field that makes systemd run the timer immediately on next boot if a scheduled run was missed. WantedBy=timers.target ensures the timer starts automatically at boot when enabled.

After creating both unit files, you need to reload systemd and start the timer. Notice that you enable and start the timer, not the service.

This is the first command to run when you want to know what's scheduled and when it last ran or will run next.

Run this when you need to confirm a timer is active, or check why a specific run didn't behave as expected.

This is the biggest day-to-day advantage over cron. Every run is logged to the journal automatically, with timestamps, exit codes, and full stdout/stderr output.

Before putting a complex schedule into a timer file, test it with systemd-analyze calendar to confirm it does what you think it does. This saves a lot of troubleshooting later.

Use OnBootSec when you want a task to run a set time after every boot, regardless of the clock. This is useful for post-boot health checks, warming caches, or syncing configs after startup.

This is the full two-file setup for a daily PostgreSQL dump at 1:30 AM. The Persistent=true line means if the server was down at 1:30 AM, the backup runs at the next boot instead of being silently skipped.

The After=postgresql.service line in the service unit is the dependency chain in action. It tells systemd not to fire the backup until PostgreSQL is confirmed running. Cron has no native way to express this.

Running Certbot via a systemd timer is cleaner than a cron job because you get full logging and Persistent=true ensures renewal still happens even if the server was off on the scheduled day.

On Ubuntu 24.04, systemd is the default init system. No extra packages needed. The only thing worth noting is that user-level timers (scoped to a login session) go in ~/.config/systemd/user/ and require --user flags.

On Rocky Linux 9 and RHEL 9, the workflow is identical to Ubuntu for system-level timers. The main difference is SELinux. If your script touches files outside its expected context, SELinux may silently block it. Check the audit log if a timer runs but produces no expected output.

This one trips up almost everyone on the first run. You write the files, then run systemctl enable mytask.service. The service gets enabled but the timer never starts, so nothing runs on schedule.

You don't need to wait for the schedule to test your service. Trigger it manually at any time with systemctl start on the service unit directly. The timer keeps running on its own schedule regardless.

The practical difference between cron and systemd timers only becomes obvious when something goes wrong. With cron, a failed job at 3 AM produces nothing visible unless you've wired up a separate logging solution or the system's mail daemon is configured and someone checks it. With systemd timers, you run journalctl -u mytask.service and see exactly what happened, when, what the script printed, and what the exit code was. For a sysadmin managing 20 scheduled tasks across production servers, that difference in observability is significant.

The automation workflow also shifts. Because each timer-driven task is a full systemd service, you can control its resource limits, set it to run as a specific user, specify dependencies on other services, and restart it on failure — all using standard systemd directives. A cron job that kills the server because it consumed unbounded CPU is a real scenario. A systemd service with CPUQuota=25% and MemoryLimit=512M in the [Service] block will never do that.

In enterprise environments running RHEL 9 or Rocky Linux 9, the audit trail from journald also matters for compliance. Log retention, structured output, and centralized logging via journald remote forwarding are all things you get for free when tasks run through systemd. Cron output forwarded through email to a root mailbox doesn't meet the same bar. You can read more about this approach in the official systemd.timer documentation, which covers every directive in detail.

None of this means cron is wrong. For a simple one-liner that runs at 4 AM on a personal server, cron is fine. But for any task where you care about reliability, logging, dependencies, or resource control, systemd timers are the better choice on modern Linux systems.