Systemd timers vs cron: which to use and when

Every Linux system needs scheduled tasks. Backups, log rotation, cleanup scripts, health checks. The two main options are cron (the classic) and systemd timers (the modern alternative). I use both depending on the situation.

Cron: the simple option

Cron has been the standard for decades. You edit a crontab file with crontab -e and add a line:

# Run backup every day at 3 AM
0 3 * * * /home/user/scripts/backup.sh
 
# Run cleanup every Sunday at midnight
0 0 * * 0 /home/user/scripts/cleanup.sh
 
# Run health check every 5 minutes
*/5 * * * * /home/user/scripts/healthcheck.sh

The format is: minute, hour, day of month, month, day of week, command.

Pros: Simple, universal, one file per user, easy to understand.

Cons: No built-in logging, no dependency management, no easy way to see if a job failed, missed jobs are not retried.

Systemd timers: the modern option

Systemd timers are the systemd-native way to schedule tasks. They require two files: a service unit (what to run) and a timer unit (when to run it).

Create /etc/systemd/system/backup.service:

[Unit]
Description=Daily backup
 
[Service]
Type=oneshot
ExecStart=/home/user/scripts/backup.sh
User=user

Create /etc/systemd/system/backup.timer:

[Unit]
Description=Run backup daily at 3 AM
 
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
 
[Install]
WantedBy=timers.target

Enable and start:

sudo systemctl enable backup.timer
sudo systemctl start backup.timer

Pros: Built-in logging (journalctl -u backup), dependency management, missed job recovery with Persistent=true, resource controls, better error visibility.

Cons: More files to manage, more verbose, overkill for simple tasks.

When I use which

Cron for: Simple one-liners, quick scripts that I do not need to monitor closely, tasks on servers where I want minimal configuration.

# Cron is perfect for this
*/5 * * * * curl -s https://status.example.com/ping > /dev/null

Systemd timers for: Important tasks (backups, maintenance), anything where I need to know if it failed, tasks with dependencies, jobs that should be retried if missed.

The backup example above benefits from systemd because Persistent=true means if the server was off at 3 AM, the backup runs when it boots up. Cron would just skip it.

Checking timer status

# List all active timers
systemctl list-timers
 
# Check a specific timer
systemctl status backup.timer
 
# See the service logs
journalctl -u backup.service --since today

This visibility is the biggest advantage of systemd timers. With cron, checking if a job ran means digging through log files or adding your own logging to every script.

The practical choice

For most homelab and server tasks, I default to systemd timers because the logging and reliability features are worth the extra configuration. For quick automation that does not need monitoring, cron's simplicity wins.

If you are not sure, start with cron. If you find yourself adding logging and error handling to every cron script, switch to systemd timers.

Sources

• systemd Timer Documentation
• Crontab Guru