Cron Expression Guide: Five Fields, Next Runs
Paste the expression and look at the next few run times; it is faster than counting asterisks against the docs. Running it once before you ship prevents most of the never-fired-in-production surprises.
When it is worth parsing first
Taking over someone's crontab is mostly a question of intent: is 0 3 * * 1-5 every day at 3, or weekdays at 3? You have to compute it before you dare change it. The same goes for your own expressions, especially with */n, ranges and lists mixed together.
The other case is the job that runs sometimes. The cause usually sits in the expression itself — a month and day pair that skips whole months, an eight-hour time-zone gap, or a 31st that February never reaches. Listing the next run times makes all of that obvious.
Reading the five fields, and where it goes wrong
The fields are minute 0-59, hour 0-23, day of month 1-31, month 1-12, day of week 0-7 where both 0 and 7 mean Sunday. You can use a star, */n steps, a-b ranges, a,b lists, and combinations like 1-5,0. Note that */n means every nth value counted from the minimum — in effect values divisible by n — not once every n units. On the minute field the two readings agree; on the 1-31 day field, */2 selects the odd days.
Day of month and day of week are the pair people misread. In Vixie cron, the implementation behind virtually every Linux distribution, when both fields are restricted (neither is a star), they are ORed: 0 0 1 * 1 fires on the first of the month and on every Monday, not on Mondays that happen to be the first. To express AND, leave one field as a star or do the check inside the script.
- 0 3 * * * is daily at 03:00; 0 3 * * 1-5 is weekdays at 03:00; 0 0 1 * * is the first of each month at midnight
- Sunday can be 0 or 7; both work, so pick one and keep it consistent across a team
- A day field of 31 never fires in February, April, June, September or November — not a bug
- The time zone is that of the server or crontab environment, not the clock on your laptop
Limits: cron starts jobs, it does not finish them
Cron does not backfill. If the machine is off at 03:00 and comes up at 03:30, that run is gone. Nor does it wait: if a job takes longer than the interval, it starts another copy, and two processes writing the same data is where the real damage happens. Wrap long jobs in flock or move them to a queue with locking.
This tool parses the standard five-field form only. It does not expand @daily or @reboot macros, does not accept a seconds field, and does not implement Quartz extensions such as L, W or #. For second-level precision, catch-up runs or a run history, use a systemd timer, a job queue or a scheduler service.
FAQ
What does it mean when day-of-month and day-of-week are both restricted?
In standard Vixie cron the two are ORed: the job runs when either field matches. 0 0 1 * 1 means the first of the month plus every Monday, not the first of the month only when it falls on a Monday. To get AND, leave one field as a star or test the date inside the script.
How do I debug a cron job that did not run?
Check four things in order: whether the expression means what you think (compare with the next run times here), whether the server time zone matches your assumption, whether PATH and the working directory differ from your login shell so commands need absolute paths, and whether the cron log shows the run at all.
Why does a job scheduled for the 31st never run in February?
Because February has no 31st. A day field of 31 fires only in January, March, May, July, August, October and December, and the skipped months produce no error. For end-of-month work, schedule the 28th or compute the last day inside the script.
Related tool：Cron Parser