What do the five fields mean?

In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC) and day of week (0-6 or SUN-SAT, where both 0 and 7 are Sunday). A star means every value.

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

Almost certainly the day-of-month and day-of-week rule. When both fields are restricted cron runs the job when either one matches, not when both do. Leaving one as a star is the only way to get an AND.

What time zone do the next run times use?

UTC, so the answer does not depend on where you are. A real cron daemon uses the time zone of the machine it runs on, which is worth checking before relying on an exact hour — especially across a daylight-saving change, where a job can run twice or not at all.

Does it support @daily and the other shortcuts?

Yes. @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly are expanded to their five-field equivalents, which are shown so you can see exactly what they stand for.

Programming

Cron Expression Parser and Next-Run Calculator

Paste a cron expression to see what it means and the next times it will fire. Every description is derived from the parsed fields, so it is never a guess.

Cron expression

At 09:30, on Monday, Tuesday, Wednesday, Thursday and Friday.

Fields

Minute1 values

30

Hour1 values

9

Day of month

*

Month

*

Day of week

1-5

Times are UTC. A real cron daemon uses the time zone of the machine it runs on, which is worth confirming before relying on an exact hour — particularly across a daylight-saving change, where a job can run twice or not at all.

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

The five fields — minute, hour, day of month, month, day of week — are each expanded into the complete set of values they match. A star becomes every value in range, 9-17 becomes the nine hours between them, */15 becomes 0, 15, 30 and 45. Once every field is a plain set, both the description and the next run times fall out of the same data, so the two can never disagree about what the expression means.

The description is generated mechanically rather than assembled from phrase templates. A template-based describer reads beautifully for the dozen expressions its author had in mind and produces a confidently wrong sentence for everything else — which is worse than a plain one, because somebody reads "every Monday", schedules a billing run on it, and finds out in production. Every phrase here is derived from the expanded sets, so it is always literally true even where that makes it less elegant.

Next run times are found by walking the calendar forward a day at a time and testing each day against the sets, rather than by pattern-matching the text. That is why 0 0 29 2 * correctly reports the next 29 February rather than a date next month, and why an expression asking for 31 February reports no runs at all instead of silently never firing. Everything is computed and displayed in UTC — a real cron daemon uses its host’s time zone, which is its own source of surprise.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

6 fields is Quartz or Spring syntax, which adds a seconds field at the front.

0 0 5 * * *

Why:: Quartz, Spring and some Kubernetes tooling use six fields with seconds first. Standard Unix cron has five, so the same string means a different time in each.
Fix:: Drop the leading seconds field for standard cron: 0 5 * * * runs at 05:00.

0-25 is outside the hour field, which runs from 0 to 23.

0 25 * * *

Why:: Hours are counted from 0, so a day runs 0 to 23 and there is no hour 24. Writing 24 for midnight is the usual cause.
Fix:: Use 0 for midnight. 0 0 * * * runs at the start of each day.

A cron expression has five fields and this has 3.

* * *

Why:: A truncated paste, or a shorthand from a tool that fills in the remaining fields itself.
Fix:: Write all five: minute, hour, day of month, month, day of week.

The job fires far more often than the expression seems to say.

Why:: When both the day-of-month and day-of-week fields are restricted, cron runs when EITHER matches rather than both. 0 0 1 * 1 is the 1st of every month AND every Monday, which is roughly five times a month, not once.
Fix:: Leave one of the two as a star. To mean "the 1st, but only if it is a Monday", test the day inside the script instead — cron cannot express it.

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 or JAN-DEC) and day of week (0-6 or SUN-SAT, where both 0 and 7 are Sunday). A star means every value.
Why does my job run on days I did not expect?: Almost certainly the day-of-month and day-of-week rule. When both fields are restricted cron runs the job when either one matches, not when both do. Leaving one as a star is the only way to get an AND.
What time zone do the next run times use?: UTC, so the answer does not depend on where you are. A real cron daemon uses the time zone of the machine it runs on, which is worth checking before relying on an exact hour — especially across a daylight-saving change, where a job can run twice or not at all.
Does it support @daily and the other shortcuts?: Yes. @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly are expanded to their five-field equivalents, which are shown so you can see exactly what they stand for.