Cron Expression Parser

Examples

The descriptions below are what the tool prints. The run times were computed by the tool’s own function starting from 2026-10-01 08:00 with the clock set to UTC; your list starts from the current minute.

In the second row the last run of each day is 17:45, not 17:00: the hour field 9-17 includes hour 17, and the minute field fires four times within it. To stop at 17:00, write the schedule as two lines (*/15 9-16 * * 1-5 and 0 17 * * 1-5). A few inputs and the message they give:

• 0 0 * * * * (six fields, as in Spring or Quartz) → Invalid: expected 5 fields, got 6.
• 0 24 * * * → Invalid expression — check each field range. Hours run 0–23.
• 5/10 * * * * → the step error that suggests */10 or 5-59/10.
• 0 0 30 2 * → the expression is valid, but no run time is found: No run time found: no real date matches these fields (for example, February 30).

Cron Field Reference

Day of Month and Day of Week

When both day fields are restricted, a day that matches either one runs (cronie crontab(5), POSIX crontab): 0 0 1 * 1 runs on the 1st of every month and on every Monday. If either field starts with *, */2 included, both must match, as in cronie, so 0 0 */2 * 1 runs only on Mondays with an odd date. The month field always has to match.

Next run times are found however far ahead they are: 0 0 1 1 * lists January 1 of the next ten years, and 0 0 29 2 * lists February 29 of leap years. For a date that never exists, such as 0 0 30 2 *, the tool says that no run time was found.

Unsupported Syntax

# (nth weekday, as in 1#2 for the second Monday), L (last), W (nearest weekday) and ? come from Quartz and similar schedulers; standard cron does not accept them. The tool does not guess a schedule for them: it shows an error that names the part and the field, for example “1#2” in the weekday field. Values that are not plain numbers or names, such as 1.5 or monday, are also rejected. A step must follow * or a range: cronie rejects 5/10, and so does this tool; write 5-59/10 or */10.

Limits

• Local time only. Run times use the browser’s time zone. There is no time zone selector, and a CRON_TZ= line is not read; cronie uses CRON_TZ for the whole crontab.
• Daylight saving time. Times that do not exist when clocks go forward never match, as crontab(5) states. Times that occur twice when clocks go back are listed once, although cronie runs the job twice.
• English description. The plain-English sentence is generated in English on every language version of this page; field names and messages are translated.
• No @ macros. @daily, @hourly, @reboot and the other shortcuts are reported as the wrong number of fields. Write the five-field form: @daily is 0 0 * * *.
• Ten runs. The list always stops at ten; there is no “show more” or date picker.

Same Syntax, Different Schedulers

Five-field cron is shared by many systems, but they differ around the edges. GitHub Actions runs schedule workflows in UTC unless a time zone is set, never more often than every 5 minutes, and may delay runs at the start of the hour under high load. A Kubernetes CronJob accepts the @ macros and treats ? like *, which this tool rejects; set its time zone in .spec.timeZone, because CRON_TZ inside the schedule fails validation. If you need to build an expression rather than read one, the cron job generator writes it from form fields.