| Position | Field | Range | Notes |
|---|---|---|---|
| 1 | Minute | 0–59 | |
| 2 | Hour | 0–23 | 24-hour clock, no AM/PM |
| 3 | Day of month | 1–31 | |
| 4 | Month | 1–12 | or JAN–DEC |
| 5 | Day of week | 0–6 | 0 = Sunday; 7 also accepted as Sunday; or SUN–SAT |
Operators: * every value, , a list, - a range, / a step. So */15 is every fifteenth minute and 9-17 is nine through seventeen inclusive.
When both day-of-month and day-of-week are restricted, cron treats them as OR, not AND. 0 0 13 * 5 does not mean "Friday the 13th" — it means midnight on the 13th of every month and midnight every Friday. Try that example above and watch the next-run list.
To get "Friday the 13th" you need a wildcard in one field and logic in the job itself. This behaviour is specified in POSIX and is not a bug, but it has caused a great many jobs to run far more often than intended.
cron runs in the server's local timezone unless the crontab sets TZ or CRON_TZ. On a server set to America/Los_Angeles, anything scheduled between 2:00 and 3:00 a.m. is genuinely hazardous: on the spring-forward date that hour does not exist, so the job silently does not run, and on the fall-back date it exists twice, so it may run twice.
Schedule backups at 1:30 or 3:30 rather than 2:30, or set the crontab to UTC and accept that the local clock time drifts twice a year. Idempotent jobs — safe to run twice — solve the problem properly.
PATH — often just /usr/bin:/bin. A script that works interactively and fails under cron is almost always this.flock is one line and solves it.Every one of those is something we set up as part of managed IT — the unglamorous work that prevents the incident nobody hears about.
We do managed IT, networking and security for businesses across Central Oregon.
Managed IT Services Call 541-508-8797