How to read the five fields
A cron expression is five space-separated fields, always in the same order: minute, hour, day of month, month, day of week. Each field takes one of five forms.
┌───────── minute 0-59
│ ┌─────── hour 0-23
│ │ ┌───── day of month 1-31
│ │ │ ┌─── month 1-12 (or jan-dec)
│ │ │ │ ┌─ day of week 0-6 (0 = Sunday, or sun-sat)
│ │ │ │ │
* * * * *
* every value
5 exactly 5
1,3,5 a list
9-17 a range
*/15 a step, so every 15th valueSteps combine with ranges, so0-30/10means minutes 0, 10, 20, and 30. Most crons also accept three-letter names for months and days, and the shorthands@daily,@hourly, and@weekly.
The day-of-week trap
This is the single most misunderstood rule in cron, and it has broken production schedules at every company that has ever used a crontab. When both the day-of-month and day-of-week fields are restricted, cron runs the job if either field matches. Not both.
So0 0 15 * 3does not mean “midnight on the 15th, but only if it is a Wednesday”. It means “midnight on the 15th, and also every Wednesday”, which fires about five times a month instead of once or twice a year. Try that expression in the tool above and watch the run times.
When only one of the two fields is restricted, the behaviour is what you would expect:0 9 * * 1-5runs at 9am on weekdays only. The OR rule kicks in solely when both are set, so the practical advice is simple: never restrict both fields in the same expression unless you genuinely want the union.
Daylight saving will bite you
Cron schedules wall-clock time, and wall-clock time is not continuous. When a zone springs forward, an hour of local time never happens, so a job scheduled at 2:30am is skipped on that date. When it falls back, that hour happens twice, and depending on the daemon the job may run twice.
Implementations disagree about the right fix, which means portable code cannot rely on any of them. Two habits avoid the whole category: run the cron daemon in UTC, or keep schedules out of the 1am-to-3am window entirely. If a job absolutely must run exactly once per day, make it idempotent and have it check whether today's work is already done.
Standard cron versus Quartz
Copy an expression off Stack Overflow and it may not be the dialect you need. Standard Unix cron takes five fields. Quartz, used by Java schedulers, takes six or seven, adding a leading seconds field and an optional trailing year. Quartz also supportsLfor the last day of the month,Wfor the nearest weekday, and#for the nth weekday of the month. None of those work in a normal crontab.
This parser targets standard five-field cron, and when it sees a Quartz-only token it says so rather than just calling the expression invalid.
Frequently asked questions
What do the five fields mean?+
In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). Each accepts a single value, a list like 1,3,5, a range like 9-17, a step like */15, or * for every value.
Why does my job run more often than expected?+
Almost always the day-of-month and day-of-week rule. When both fields are restricted, cron fires if either one matches, not both. So 0 0 15 * 3 runs on the 15th and on every Wednesday, which is roughly five times a month rather than once a year.
What happens to a job scheduled during a daylight saving change?+
It depends on the implementation, and that is the problem. When the clock springs forward, a job scheduled in the skipped hour may be missed entirely; when it falls back, a job may run twice. Scheduling outside 1am to 3am avoids the whole class of bug, or run the daemon in UTC.
Are L, W, and ? supported?+
No, and deliberately. Those are Quartz and Spring extensions, not standard cron, so an expression using them will fail on a normal crontab. This parser flags them and says which scheduler they belong to.
Why does my expression show no run times?+
The schedule is impossible. The usual cause is a date that never occurs, such as 0 0 30 2 * for the 30th of February, or a day-of-month and month pair that never line up.