Crontab syntax
The five fields of a cron line, the shortcuts (@daily…) and common ready-to-copy examples.
The five fields
┌─────── 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
Operators
| Symbol | Meaning |
|---|---|
* |
every value |
, |
list: 1,15,30 |
- |
range: 9-17 |
*/5 |
step: every 5 units |
Shortcuts
| Shortcut | Equivalent to |
|---|---|
@hourly |
0 * * * * |
@daily |
0 0 * * * |
@weekly |
0 0 * * 0 |
@monthly |
0 0 1 * * |
@reboot |
at startup |
Examples
*/15 * * * * every 15 minutes 0 3 * * * every day at 3am 0 9 * * 1-5 at 9am on weekdays 30 2 1 * * on the 1st of each month at 2:30am
Edit:
crontab -e· list:crontab -l· redirect output:>> /var/log/mycron.log 2>&1.
Environment variables and absolute paths
Cron runs with a minimal environment (no .bashrc): always use absolute paths.
MAILTO="" PATH=/usr/local/bin:/usr/bin:/bin 0 2 * * * /usr/local/bin/my-script.sh
A script that works perfectly from the command line can fail silently in cron if $PATH doesn't contain the same directories as your interactive session.
Testing and debugging a cron job
crontab -l # list current jobs grep CRON /var/log/syslog # check if/when a job fired (Debian/Ubuntu) run-parts --test /etc/cron.daily # simulate system jobs without running them
To debug a command that fails silently, first test it with exactly the same environment cron uses: env -i /bin/sh -c 'your-command'.
Cron vs. systemd timers
| Cron | systemd timers | |
|---|---|---|
| Configuration | One line in a crontab file | Two unit files (.service + .timer) |
| Logging | You handle it yourself (redirection) | Built in, via journalctl |
| Dependencies | No native handling | Can depend on other services |
| Simplicity | Very simple for one isolated job | More verbose, but more robust at scale |
Thanks for the feedback!