Timers vs Cron

Timers vs Cron

Systemd timers are an alternative to cron for scheduling recurring tasks. Unlike cron, timers integrate with journald (so all output is logged automatically), support transient timers without editing config files, and handle missed runs when the system was offline. Understanding the tradeoffs helps you choose the right tool for each job.

Why consider systemd timers?

Creating a timer pair

A systemd timer consists of two unit files with the same name: a .timer file (when to run) and a .service file (what to run).

# Create the service unit (what to run)
sudo nano /etc/systemd/system/backup-home.service

/etc/systemd/system/backup-home.service

[Unit]
Description=Daily backup of /home to /backup
After=local-fs.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/bin/rsync -av --delete /home/ /backup/home/
StandardOutput=journal
StandardError=journal

# Create the timer unit (when to run)
sudo nano /etc/systemd/system/backup-home.timer

/etc/systemd/system/backup-home.timer

[Unit]
Description=Run home backup daily at 2am

[Timer]
OnCalendar=daily
RandomizedDelaySec=900     # Random delay up to 15min (spread load on multiple servers)
Persistent=true            # Run missed jobs when system comes back online

[Install]
WantedBy=timers.target

# Enable and start the timer
sudo systemctl daemon-reload
sudo systemctl enable --now backup-home.timer

# Run the job immediately to test it
sudo systemctl start backup-home.service

# View logs
sudo journalctl -u backup-home.service -n 50

OnCalendar syntax

# Common OnCalendar values:
OnCalendar=daily          # Every day at midnight (00:00:00)
OnCalendar=weekly         # Every Monday at midnight
OnCalendar=monthly        # First day of each month at midnight
OnCalendar=hourly         # Every hour on the hour

# Custom schedule syntax: DayOfWeek Year-Month-Day Hour:Minute:Second
OnCalendar=*-*-* 02:00:00     # Every day at 2:00 AM
OnCalendar=Mon *-*-* 04:00    # Every Monday at 4:00 AM
OnCalendar=*-*-1 03:00:00     # First day of every month at 3am
OnCalendar=Sat,Sun *-*-* 10:00:00  # Weekends at 10am

# Relative timers (run after boot or last activation)
OnBootSec=5min        # Run 5 minutes after system boots
OnActiveSec=1h        # Run every hour after last activation
OnUnitActiveSec=1d    # Run 24h after the service last ran

# Test calendar expressions without deploying
systemd-analyze calendar "Mon *-*-* 04:00"

Viewing timer status

# List all active timers with next trigger time
systemctl list-timers

systemctl list-timers output

NEXT                         LEFT          LAST                         PASSED       UNIT                    ACTIVATES
Mon 2026-06-10 02:00:00 UTC  9h left       Sun 2026-06-09 02:00:00 UTC  13h ago      backup-home.timer       backup-home.service
Mon 2026-06-10 00:00:00 UTC  7h left       Sun 2026-06-09 00:00:00 UTC  15h ago      logrotate.timer         logrotate.service

# Check specific timer status
systemctl status backup-home.timer

# View logs of last run
journalctl -u backup-home.service --since "24 hours ago"

When cron is still the right choice

• You need per-user scheduling (user crontabs) without root
• Simpler one-off jobs that don’t need logging or dependencies
• The team is more familiar with cron and there’s no strong benefit to switching
• Short-lived simple scripts where the systemd overhead isn’t justified

Conclusion

Systemd timers are better than cron for production server tasks because output is automatically logged to journald, missed runs can be recovered with Persistent=true, and resource limits can be applied to the service unit. The tradeoff is two files instead of one cron line. Use systemctl list-timers to see when all scheduled jobs last ran and when they run next — something cron cannot tell you without inspecting log files manually. Use systemd-analyze calendar to verify your schedule expressions before deploying.