{"id":842,"date":"2026-08-11T02:18:02","date_gmt":"2026-08-11T02:18:02","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=842"},"modified":"2026-08-11T02:18:02","modified_gmt":"2026-08-11T02:18:02","slug":"systemd-timers-vs-cron-scheduling-jobs-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/systemd-timers-vs-cron-scheduling-jobs-vps\/","title":{"rendered":"systemd Timers vs cron: Scheduling Jobs on a VPS"},"content":{"rendered":"\n

Goal: choose the right scheduler for recurring jobs on a Linux VPS and migrate your crontab to systemd timers where it pays off. This guide compares both, shows a working timer unit, and covers the pitfalls (missed runs, timezone handling, resource limits). Prerequisites: root access and a few cron jobs you are willing to experiment on.<\/p>\n\n\n

When cron is still the right tool<\/h2>\n\n\n

Cron remains the simplest option for basic jobs: one line in a crontab, no unit files, no daemon-reload. It is fine for log rotation triggers, simple cleanup scripts, and anything that must run at an exact wall-clock minute. It falls short when you need dependencies, missed-run catch-up, sandboxing, or per-service resource limits \u2014 all of which systemd timers provide natively.<\/p>\n\n\n

Anatomy of a systemd timer<\/h2>\n\n\n

A timer needs two unit files. The service holds the command; the timer schedules it:<\/p>\n\n\n

# \/etc\/systemd\/system\/backup.service\n[Unit]\nDescription=Nightly offsite backup\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/sbin\/backup.sh\nUser=backup\n\n# \/etc\/systemd\/system\/backup.timer\n[Unit]\nDescription=Run backup nightly at 02:30\n\n[Timer]\nOnCalendar=*-*-* 02:30:00\nPersistent=true\n\n[Install]\nWantedBy=timers.target<\/code><\/pre>\n\n\n
Enable both:<\/p>\n\n\n
sudo systemctl daemon-reload\nsudo systemctl enable --now backup.timer\nsystemctl list-timers backup.timer<\/code><\/pre>\n\n\n
The Persistent=true<\/code> line is the killer feature: if the machine was off at 02:30, the job runs immediately at next boot. Cron simply drops missed runs.<\/p>\n\n\n
Calendar vs monotonic scheduling<\/h2>\n\n\n
Timer type<\/th>Directive<\/th>Use case<\/th><\/tr><\/thead>
Wall-clock<\/td>OnCalendar=*-*-* 02:30:00<\/td>Nightly backups, log rotation, TLS renewal<\/td><\/tr>
Daily offset<\/td>OnCalendar=daily<\/td>Simple daily jobs at midnight<\/td><\/tr>
Monotonic<\/td>OnUnitActiveSec=6h<\/td>Jobs that must run every N hours since last run<\/td><\/tr>
Monotonic<\/td>OnBootSec=5min<\/td>One-off startup tasks after boot<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n
Use monotonic timers for jobs whose spacing matters (health checks, cache warmers) and calendar timers for jobs that must align with wall-clock time. You can combine both in one timer; the job runs when either condition fires.<\/p>\n\n\n
Missed runs, timezones, and randomization<\/h2>\n\n\n
Set the timer’s timezone explicitly or inherit the system one; a VPS with UTC while your users are in UTC+2 will fire at the wrong local hour. Add RandomizedDelaySec=10m<\/code> to spread load, and use AccuracySec=1m<\/code> when you need precise firing. Check the next run with:<\/p>\n\n\n
systemctl list-timers --all\nsystemd-analyze calendar backup.timer<\/code><\/pre>\n\n\n
OnCalendar syntax examples<\/h2>\n\n\n
The calendar syntax is more flexible than cron’s five fields. Common patterns:<\/p>\n\n\n
Intention<\/th>cron equivalent<\/th>OnCalendar value<\/th><\/tr><\/thead>
Every day at 02:30<\/td>30 2 * * *<\/td>*-*-* 02:30:00<\/td><\/tr>
Every Monday 03:00<\/td>0 3 * * 1<\/td>Mon *-*-* 03:00:00<\/td><\/tr>
First day of month 04:00<\/td>0 4 1 * *<\/td>*-*-01 04:00:00<\/td><\/tr>
Every 15 min<\/td>*\/15 * * * *<\/td>*:0\/15<\/td><\/tr>
Twice a day<\/td>0 *\/12 * * *<\/td>*-*-* 00,12:00:00<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n
Validate any expression before deploying it \u2014 a typo silently never fires. systemd-analyze calendar<\/code> prints the next 10 occurrences so you can eyeball them.<\/p>\n\n\n
Cron pitfalls timers eliminate<\/h2>\n\n\n