Crontab vs
Systemd Timers

Quick Answer: When to Use Each

Side-by-Side: Cron vs Systemd Timer

Converting Cron Expressions to Systemd OnCalendar

Systemd timers use OnCalendar= in the [Timer] section. The syntax is different but more readable than cron's 5-field format.

Crontab: Full Example

# /etc/cron.d/backup-job or crontab -e
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""

# Daily database backup at 2 AM
0 2 * * *  root  /usr/local/bin/db-backup.sh >> /var/log/db-backup.log 2>&1

Systemd Timer: Equivalent Setup

A systemd timer requires two files: a .service unit (what to run) and a .timer unit (when to run it).

Step 1: Service unit — /etc/systemd/system/db-backup.service

[Unit]
Description=Daily Database Backup
After=network.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/db-backup.sh
StandardOutput=journal
StandardError=journal

Step 2: Timer unit — /etc/systemd/system/db-backup.timer

[Unit]
Description=Run db-backup daily at 2 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true         # Run after reboot if missed
RandomizedDelaySec=300  # Add up to 5min random delay

[Install]
WantedBy=timers.target

Step 3: Enable and start the timer

sudo systemctl daemon-reload
sudo systemctl enable db-backup.timer
sudo systemctl start db-backup.timer

# Check status
systemctl status db-backup.timer
systemctl list-timers --all

Check logs

# All output from the job — no log file setup needed
journalctl -u db-backup.service

# Follow logs in real time
journalctl -u db-backup.service -f

# Logs from the last run only
journalctl -u db-backup.service --since "1 day ago"

Missed Run Recovery with Persistent=true

This is one of systemd timers' biggest advantages over cron. With Persistent=true, systemd records the last time the timer fired. If the system was powered off during a scheduled run, the timer fires once immediately on the next boot.

[Timer]
OnCalendar=daily
Persistent=true   # Fire on boot if last run was missed

This is critical for jobs like nightly backups on machines that aren't always on (laptops, development servers). With cron, if the machine is off at 2 AM, the backup simply never runs. With a persistent systemd timer, it runs as soon as you boot the next morning.

Testing Systemd Calendar Expressions

Systemd ships with a built-in tool to validate calendar expressions and preview the next run times:

# Test a calendar expression
systemd-analyze calendar "Mon..Fri *-*-* 09:00:00"

# Output:
#   Original form: Mon..Fri *-*-* 09:00:00
# Normalized form: Mon..Fri *-*-* 09:00:00
#     Next elapse: Mon 2026-05-04 09:00:00 IST
#        (in UTC): Mon 2026-05-04 03:30:00 UTC
#       From now: 3 days 21h left

# Test @shortcuts
systemd-analyze calendar daily
systemd-analyze calendar weekly

Migrating from Crontab to Systemd Timers — Practical Guide

If you are running a modern Linux distribution (Ubuntu 20.04+, Debian 11+, RHEL 8+) and want to migrate an existing crontab to systemd, here is the recommended workflow:

Step 1: Audit your current crontab

Run crontab -l and cat /etc/cron.d/* to list all scheduled jobs. Group them by owner and frequency. Jobs that need dependency management, restart policies, or logging to the journal are the best candidates to migrate first.

Step 2: Convert the schedule expression

Use systemd-analyze calendar "Mon *-*-* 04:00:00" to validate the OnCalendar value before writing the timer unit. The --iterations=5 flag shows the next 5 matching times — equivalent to using CronRead's next-run-times feature for cron expressions. See the conversion table above for cron-to-OnCalendar mappings.

Step 3: Decide on Persistent=true

If the job must not be missed (database backups, billing jobs, compliance reports), set Persistent=true in the timer unit. This instructs systemd to trigger the service immediately on boot if the last scheduled run was missed — for example, because the server was down. Standard cron silently skips missed runs with no recovery.

Step 4: Verify and monitor

After enabling the timer with systemctl enable --now my-job.timer, verify it with systemctl list-timers --all to confirm the next trigger time. Use journalctl -u my-job.service -f to follow live output. Systemd automatically logs start time, exit code, and duration to the journal — no manual log redirection needed.

When to Keep Crontab Instead of Migrating

Systemd timers are more powerful, but crontab is still the right choice in several common situations:

• Container environments (Docker, Kubernetes): Containers typically don't run systemd. Use cron inside Docker via a CMD crond -f entrypoint or a dedicated scheduler like supercronic. For Kubernetes, use a native CronJob resource instead of crontab or systemd.
• Non-root user jobs: Each Linux user can have their own crontab without needing root access. Systemd user-scope timers require more setup (systemctl --user) and loginctl linger to run without an active session.
• Quick one-off additions: Adding a job with crontab -e takes 10 seconds. Creating a service unit + timer unit + enabling it takes 2–3 minutes. For a simple log-rotation or cache-clear job, crontab's simplicity wins.
• Shared hosting or managed servers: Many environments don't give you systemd access. Crontab is universally available anywhere you have a login shell.

Frequently Asked Questions

Related Guides