scriptiii
100% Client-Side

5-field cron

Cron expression parser

Read a five-field cron expression: what each field selects, when it next runs, and the either/or rule between day-of-month and day-of-week.

minute · hour · day-of-month · month · day-of-week

The expression is parsed in this tab against your own clock. Nothing is scheduled, submitted or sent anywhere.

Short answer: paste the expression and every field is spelled out with the next five run times. If both day fields are set, the tool says so, because cron then runs on either match — the single most common source of "why did this fire today".

The rule that surprises everyone

In Vixie cron, when day-of-month and day-of-week are both restricted, the condition isdom OR dow, not dom AND dow. 0 12 1 * MON runs at noon on the first of the month and also every Monday. To restrict to a Monday that is also the first, the expression has to be expressed differently — usually by checking the date in the job itself.

Syntax this parser accepts

Quartz-only tokens (L, W, #) and six-field expressions with seconds are refused with an explanation instead of being half-interpreted.

Cron questions

What order are the fields in?

Minute, hour, day of month, month, day of week. For example, 30 9 * * MON-FRI means 09:30 every weekday. Ranges (9-17), lists (1,15) and steps (*/15) are supported, as are the three-letter month and weekday names.

Why does my job run on days I did not expect?

When both day-of-month and day-of-week are restricted, cron runs the job when either matches — not both. So 0 12 1 * MON runs on the first of the month AND every Monday. The parser states this explicitly when it applies.

Which time zone are the next runs in?

Your device time zone, because that is what a cron daemon on your machine evaluates. A server in another region will fire at a different instant; convert with the timestamp tool if you need to compare.

Is this the same as every cron implementation?

It is five-field Vixie cron, which is what the standard crontab uses. Quartz adds seconds and tokens such as L, W and #, so those expressions are refused with an explanation. GitHub Actions and Kubernetes use their own dialects and should be checked against their documentation.

What happens with an impossible expression?

Something like 0 0 30 2 * parses cleanly but can never match a real date. The search is bounded to five years and then reports that, rather than looping forever or pretending the next run is in February.

Related tools

Unix timestamp converterCheck what a server clock will see.Regex testerValidate the log line the job writes.JSON formatterPretty-print the job config around it.All developer toolsEvery tool in the developer group.