Cron Jobs Done Right: Scheduling That Doesn't Break
Cron is deceptively simple. Here's how to write jobs that run reliably and don't wake you up at 3 AM.
February 24, 2026 · 7 min · 1349 words · Rob Washington
Table of Contents
Cron has been scheduling tasks on Unix systems since 1975. It’s simple, reliable, and available everywhere. But that simplicity hides gotchas that break jobs in production.
# Every minute* * * * * /path/to/script.sh
# Every hour at minute 00 * * * * /path/to/script.sh
# Every day at midnight00 * * * /path/to/script.sh
# Every day at 2:30 AM302 * * * /path/to/script.sh
# Every Monday at 9 AM09 * * 1 /path/to/script.sh
# Every 15 minutes*/15 * * * * /path/to/script.sh
# Every weekday at 6 PM018 * * 1-5 /path/to/script.sh
# First day of every month at midnight001 * * /path/to/script.sh
# Edit current user's crontabcrontab -e
# List current user's crontabcrontab -l
# Edit another user's crontab (as root)crontab -u username -e
# Remove all cron jobs (careful!)crontab -r
# System-wide crontab (includes user field)/etc/crontab
# Drop-in directory (no user field needed)/etc/cron.d/
# Periodic directories (scripts run by run-parts)/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
# Bad - relies on user PATH* * * * * backup.sh
# Good - explicit path* * * * * /usr/local/bin/backup.sh
# Or set PATH in crontabPATH=/usr/local/bin:/usr/bin:/bin
* * * * * backup.sh
Cron’s simplicity is its strength and weakness. The syntax is easy to learn, but the minimal environment trips up everyone at least once. Set your PATH, lock your jobs, log your output, and you’ll have cron jobs that run reliably for years.
📬 Get the Newsletter
Weekly insights on DevOps, automation, and CLI mastery. No spam, unsubscribe anytime.