Cron expression parser and next run times

How to use it

1. Paste a cron expression or click one of the common ones. Standard 5-field expressions are supported, as are 6-field expressions with a leading seconds field and shortcuts such as @daily and @hourly.
2. Choose the time zone. It defaults to your computer's; server cron jobs run in the server's time zone, which is often UTC, so check that before reading the times.
3. Read the one-sentence description, the table of what each field means, and the next run times with how far away each one is.

The rules

Five fields

According to the crontab(5) manual, the fields are 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 are Sunday). Months and weekdays can also be written as their first three letters, such as jan or mon, in any case. A field can be * for every value, a comma-separated list (1,15), a range (1-5; the start may not exceed the end) or a step: */15 means every 15th value and 0-23/2 every other hour. @yearly, @monthly, @weekly, @daily and @hourly stand for 0 0 1 1 *, 0 0 1 * *, 0 0 * * 0, 0 0 * * * and 0 * * * *.

The classic mistake: day of month OR day of week

The POSIX specification says that when both day fields are restricted, a day matching either one is enough. The manual's example, 30 4 1,15 * 5, runs at 4:30 on the 1st and 15th of each month plus every Friday — not "on the 1st or 15th when it is a Friday". People who want "the first Monday of the month" often write 0 9 1-7 * 1 and get every day from the 1st to the 7th plus every Monday.

A lesser-known detail: the manual counts a field as restricted only when it does not contain the * character. A step such as */2 starts with an asterisk, so it does not count, and then both fields must match: 0 0 */2 * 1 means "an odd day of the month that is also a Monday". The tool follows these rules and warns you whenever either case applies.

Time zones and daylight saving

Cron matches against the clock of the machine it runs on. The manual notes that when daylight saving time changes, jobs scheduled in the skipped hour do not run, and jobs in the repeated hour run twice. If your server's time zone observes daylight saving, be careful with jobs scheduled around the change-over in the early morning. The tool calculates in the chosen zone's wall-clock time and does not adjust for these transitions.

Six fields, and a Quartz warning

Spring's scheduler uses six fields with seconds first; its day of week is also 0–7 with Sunday as 0 or 7, and ? can replace * in the day fields. The tool parses 6-field expressions that way and accepts ?.

Be careful with Quartz: its day of week runs 1–7 with 1 meaning Sunday and 2 Monday, one off from Unix cron. It also has an optional seventh field for the year and the extensions L (last), W (nearest weekday) and # (nth weekday). A Quartz expression pasted here will be read with Unix weekday numbers, so convert it yourself.

Examples

Starting from Wednesday 30 September 2026 at 10:07:

0 0 30 2 * never runs, because February has no 30th, and the tool says so. 0 0 31 * * runs only in months with 31 days, so after 31 October the next run is 31 December.

Limits

• Quartz extensions (L, W, #, the year field) and cronie's ~ random ranges are not supported, and Quartz weekday numbers (1 = Sunday) differ from those used here.
• The form 5/15 ("from 5, every 15") is accepted as many implementations do, but not every cron supports it.
• Times are wall-clock times in the chosen zone; skipped and repeated times on daylight-saving change-over days are not adjusted.
• Only the expression is evaluated. Whether a job actually runs also depends on the cron service running, the machine being on and any other conditions on the job.

Sources and further reading

• POSIX: crontab
• crontab(5) manual (man7.org)
• Spring Framework: Task Execution and Scheduling (cron expressions)
• Quartz Scheduler: CronTrigger tutorial