Cron concepts
Cron is the Unix scheduler — learn to read and write crontab expressions, understand common schedule patterns, and know where cron falls short.
- Read a crontab expression by understanding its five fields
- Write expressions for common schedules (daily at midnight, every 5 minutes, weekly on Monday)
- Explain cron's limitations around dependency tracking and retry
Once a script is working, the next question is: when does it run? The answer on most Unix-like systems is cron — a daemon that reads a schedule table and runs commands at the specified times. Cron has been around since 1975. It is available on every Linux server and macOS machine. Learning to read and write cron schedules is a baseline skill for anyone automating tasks.
The five fields
A crontab entry has six parts: five timing fields and the command to run.
* * * * * command to execute
│ │ │ │ │
│ │ │ │ └── Day of week (0-7, where 0 and 7 are Sunday)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)A * in any field means "every value for that field." So * * * * * runs every
minute, every hour, every day.
Common patterns
| Expression | Meaning |
|---|---|
0 0 * * * | Daily at midnight |
0 9 * * 1 | Monday at 9am |
*/5 * * * * | Every 5 minutes |
0 */6 * * * | Every 6 hours (00:00, 06:00, …) |
30 8 1 * * | First day of month at 8:30am |
0 0 * * 0 | Every Sunday at midnight |
The */n syntax means "every n units": */5 in the minute field means minutes 0, 5,
10, 15, and so on. */6 in the hour field means hours 0, 6, 12, 18.
crontab.guru is the standard tool for translating cron expressions into plain English. Paste any expression and it tells you exactly what it means and when it next runs. Use it — even experienced users check unusual expressions.
Editing and viewing the crontab
crontab -e # open your crontab for editing
crontab -l # list current entriesA full crontab entry for a Python script:
0 9 * * 1-5 /usr/bin/python3 /home/user/scripts/daily_report.py >> /home/user/logs/report.log 2>&1The >> logfile 2>&1 appends stdout and stderr to a log file — cron itself has no
log UI, so redirecting output is essential. Without it, any output goes to the system
mail queue (or disappears).
Cron's limitations
Cron works well for simple, time-based triggers. It has notable gaps:
- No dependency tracking. Cron does not know if one job should wait for another to finish. If job A produces data that job B needs, you have to sequence them by time (run A at 08:00, B at 08:30) and hope A always finishes in time.
- No built-in retry. If a job fails, cron does not retry it. You have to build retry logic into the script itself or use a wrapper.
- No overlap protection. If a job runs longer than its interval, the next instance starts anyway. Two instances of the same script can run simultaneously.
- Opaque error handling. A failed job produces no visible alert unless you explicitly set up email or log monitoring.
For more sophisticated scheduling needs — dependencies, retries, overlap prevention, monitoring — tools like Apache Airflow, Prefect, or even simple Python schedulers are the right escalation path.
Where to go next
Next: Python schedulers — running schedules inside a Python process using the
schedule library, which is simpler than cron for scripts that are already running
persistently.
Lab: Subprocess pipeline
Build a script that generates a file list with a system call, processes metadata in Python, and writes a JSON summary — end-to-end practice for the shell and processes module.
Python schedulers
The schedule library lets you define recurring jobs with readable syntax inside a Python process — a practical alternative to cron for scripts you control directly.