Almost every server runs tasks on a schedule: nightly backups, log rotation, certificate renewals, cache clearing, sending reports. On Linux, the tool that makes this happen is cron — a time-based job scheduler that has quietly run the internet’s housekeeping for decades. This guide explains how cron works, how to read and write the crontab syntax, and the practical habits that stop scheduled jobs from failing silently.

What Is Cron?

Cron is a daemon that runs continuously in the background and checks, every minute, whether any scheduled job is due. The schedules live in crontab (“cron table”) files. Each user can have their own crontab, and the system has its own for administrative tasks.

crontab -e      # edit your crontab
crontab -l      # list your current jobs
crontab -r      # remove your crontab (careful!)

Understanding the Crontab Syntax

Each cron job is one line with five time fields followed by the command to run:

# ┌───────────── minute (0–59)
# │ ┌───────────── hour (0–23)
# │ │ ┌───────────── day of month (1–31)
# │ │ │ ┌───────────── month (1–12)
# │ │ │ │ ┌───────────── day of week (0–7, 0 and 7 = Sunday)
# │ │ │ │ │
# * * * * *  command-to-run

The special characters do the heavy lifting: * means “every,” , lists values, - gives a range, and / sets a step interval.

Common Schedule Examples

Schedule	Meaning
0 2 * * *	Every day at 2:00 AM
*/15 * * * *	Every 15 minutes
0 */6 * * *	Every 6 hours
30 3 * * 0	Every Sunday at 3:30 AM
0 0 1 * *	Midnight on the 1st of each month
0 9-17 * * 1-5	Hourly, 9 AM–5 PM, Mon–Fri

Many cron implementations also accept shortcuts like @daily, @hourly, @weekly, and @reboot (run once at startup).

Capturing Output and Logs

By default, cron emails any output to the user. On most servers that mail goes nowhere, so jobs fail silently. The fix is to redirect output to a log file:

# Append both standard output and errors to a log
0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

# Discard output entirely (only when you're sure it's stable)
*/5 * * * * /usr/local/bin/healthcheck.sh >/dev/null 2>&1

Common Pitfalls

• No PATH — cron runs with a minimal environment. Always use absolute paths to commands and scripts (/usr/bin/php, not php).
• Wrong timezone — cron uses the system timezone; verify it with timedatectl.
• The percent sign — % has special meaning in crontab and must be escaped as \%.
• Script not executable — remember chmod +x and a correct shebang line.

Testing Before You Trust It

Don’t wait until 2 AM to discover a job is broken. Temporarily schedule it for the next minute, watch the log, then set the real schedule. You can also run the exact command manually first — if it works by hand with full paths, it’ll work in cron.

Conclusion

Cron is simple once the five-field syntax clicks: minute, hour, day-of-month, month, day-of-week, then the command. Use absolute paths, redirect output to a log so nothing fails silently, and test on a short schedule before going live. Master it and your server’s routine maintenance runs itself — reliably, around the clock.