Cron Expression Parser

This cron expression parser tells you what a five-field schedule actually means: a plain-English description, the next ten run times in your local time zone, and a breakdown of every field. Shorthands like @daily and @weekly are supported too.

How to use Cron Expression Parser

  1. Type or paste a cron expression such as */15 9-17 * * 1-5, or choose one of the presets.
  2. Read the plain-English description generated from the parsed fields.
  3. Check the next ten scheduled run times, calculated in your device’s local time zone.
  4. Use the field breakdown table to confirm exactly which minutes, hours, days and months are selected.
  5. Fix any error using the message, which names the offending field and the value that is out of range.

About Cron Expression Parser

Cron syntax is compact to the point of hostility. Five fields, five different value ranges, and four operators that combine in ways that are easy to write and hard to read back — which is why almost everyone who edits a crontab does so slightly nervously. The single most valuable thing a parser can do is restate the expression in a sentence and then show the actual timestamps it produces, because a schedule that reads correctly and fires wrongly is the failure mode that costs a weekend.

This parser expands each field into its concrete set of values, so */15 becomes minutes 0, 15, 30 and 45 and 9-17 becomes nine hours, and shows those sets in a breakdown table. The next ten run times are then computed by walking forward from now, skipping whole days that cannot match before checking hours and minutes. It also implements the day-of-month versus day-of-week rule correctly: when both fields are restricted the match is a union, not an intersection — a quirk inherited from the original Unix implementation that surprises people every single time.

Validation is specific rather than binary. Instead of "invalid expression", errors name the field, the token and the legal range — a month of 13 or a step of zero is reported where it occurs. Named values such as MON and JAN are accepted, as are the @hourly through @yearly shorthands. One caveat worth repeating: the previews here use your device’s local time zone, while a cron daemon uses its host’s, so a container running in UTC will not necessarily agree with your laptop.

Frequently asked questions

What do the five cron fields mean?

In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–7, where both 0 and 7 mean Sunday). Each accepts * for every value, a list such as 1,15, a range such as 9-17 and a step such as */15.

What does */5 actually mean?

A step. */5 in the minute field means every fifth minute starting at zero — 0, 5, 10 and so on — not "every five minutes from now". Steps can also apply to a range, so 10-40/10 means minutes 10, 20, 30 and 40.

How are day-of-month and day-of-week combined?

This is the classic trap. If both fields are restricted, cron runs when either matches, not both — so 0 0 13 * 5 fires on the 13th of every month and on every Friday. If one of the two is *, only the other applies. This parser follows that rule.

Which time zone are the next runs shown in?

Your device’s local time zone, including daylight-saving transitions. Real cron daemons use the server’s zone — often UTC in a container — so always confirm which zone your scheduler runs in before trusting a schedule that straddles a DST change.

Are shorthands like @daily supported?

Yes. @hourly, @daily (also written @midnight), @weekly, @monthly and @yearly (or @annually) are expanded to their five-field equivalents and described the same way.

What about six-field expressions with seconds?

Quartz, Spring and some container schedulers add a leading seconds field, and Quartz also supports L, W and #. This parser targets standard five-field Unix crontab syntax and will tell you clearly when an expression uses an extension it does not implement.

Related tools

All developer tools · Browse all 56 free tools →