cron vs systemd Timers: Scheduling Jobs on Modern Linux

Every Linux system needs scheduled jobs: rotating logs, running backups, sending health-check pings, cleaning temporary files, renewing TLS certificates. For decades, cron was the only reliable answer. Today, systemd ships its own scheduling mechanism in the form of timers. Both solve the same problem, but they have different strengths. This guide compares them and shows when to use each.

How Cron Works

Cron reads the crontab and runs commands on a schedule. To see or edit your jobs:

crontab -e
crontab -l
crontab -u deploy -e

Each line has five time fields followed by the command:

0 3 * * * /usr/local/bin/backup-db.sh
*/30 * * * * /usr/local/bin/healthcheck.sh
30 2 * * 1 tar czf /backups/logs-$(date +%F).tar.gz /var/log/

The five fields are minute, hour, day of month, month, and day of week. The first line runs the database backup daily at 3:00 AM. The second runs every 30 minutes. The third runs a log archive every Monday at 2:30 AM.

Cron jobs run in a minimal environment without the user's shell settings, PATH, or environment variables. A common failure mode is a script that works fine in an interactive terminal but fails under cron because a tool is not on the default PATH. Always call absolute paths or source your environment inside the script.

How systemd Timers Work

A systemd timer pairs a .timer unit with a .service unit. The service unit runs the actual job, and the timer decides when to trigger it. A minimal example:

# /etc/systemd/system/backup-db.timer
[Unit]
Description=Run database backup daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

# /etc/systemd/system/backup-db.service
[Unit]
Description=Database backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-db.sh

Activate the timer and check it like any other unit:

systemctl enable --now backup-db.timer
systemctl list-timers
systemctl status backup-db.timer

The date and time syntax for OnCalendar is flexible and human-readable. OnCalendar=daily means 00:00 daily. You can also use OnCalendar=*-*-* 03:30:00 for a specific time, or OnCalendar=Mon *-*-* 02:30:00 for a weekly job.

Why Timers Are Often Better

systemd timers offer several concrete advantages over cron:

• **Missed jobs are caught up**: Persistent=true runs a missed job as soon as the machine is back online, instead of silently skipping it.
• **Structured output**: Job logs go to the journal via journald, so you inspect failures with journalctl -u backup-db.service.
• **Dependencies**: You can gate a timer behind After=network-online.target so remote jobs only run after networking is up.
• **Randomized delays**: RandomizedDelaySec staggers jobs to avoid thundering-herd CPU spikes on shared systems.
• **Full systemd integration**: systemctl list-timers shows the next run time in one convenient table.

For a single VPS, cron is simpler to get started and perfectly reliable. For anything that requires dependent startup, catch-up semantics, or journaled output, timers win.

Best Practices for Scheduling

• Always test the underlying command manually before scheduling it.
• Log output so failures are visible. With cron, redirect: script.sh >> /var/log/job.log 2>&1.
• Use Persistent=true for jobs that must not be skipped.
• Monitor systemctl list-timers to confirm every schedule is armed.

Takeaway

Use cron when you need a quick, well-understood schedule, and switch to systemd timers when you need persistence, journaled logs, or dependency ordering. Automate your first scheduled job on a Netbay Linux VPS in minutes at netbayhosts.in.