Scheduling: cron & systemd timers
Run jobs on a schedule with cron syntax and modern systemd timers.
Scheduled jobs power backups, cleanups, and reports. cron is the classic scheduler. A crontab line has five time fields plus a command:
┌ minute ┌ hour ┌ day-of-month ┌ month ┌ day-of-week
* * * * * commandsystemd timers are the modern alternative: a .timer unit triggers a
.service unit. They add nice features cron lacks — calendar syntax, missed-run
catch-up (Persistent=true), logging via the journal, and dependencies.
# crontab -e
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 # 2am daily
*/15 * * * * /usr/local/bin/healthcheck.sh # every 15 min
0 9 * * 1 /usr/local/bin/weekly-report.sh # Mondays 9am# /etc/systemd/system/backup.timer
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.target
# enable with: systemctl enable --now backup.timer- Write a cron line that runs a script every weekday at 6:30 PM.
- Use crontab.guru to decode
30 3 1 * *. - Redirect a cron job’s output and errors to a log file.
- Convert a cron schedule into a systemd timer
OnCalendar=expression.
Cheat Sheet▾
| Schedule | cron |
|---|---|
| Every minute | * * * * * |
| Every 15 min | */15 * * * * |
| Daily 2am | 0 2 * * * |
| Mondays 9am | 0 9 * * 1 |
| Edit crontab | crontab -e |
| List crontab | crontab -l |
| systemd timer | OnCalendar= + systemctl enable --now x.timer |
Common Interview Questions▾
What are the five fields of a cron expression?
Minute, hour, day-of-month, month, and day-of-week, followed by the command. An asterisk means “every”.
Why might a script work in your shell but fail under cron?
cron runs with a minimal environment (bare PATH, no profile). Missing absolute paths or env vars cause failures. Use full paths and set needed variables.
What advantages do systemd timers have over cron?
Calendar syntax, catch-up for missed runs (Persistent), integrated journal logging, dependencies on other units, and easier per-job resource control.