Cron Generator & Parser

Type an expression and read straight away when it fires – or click one together field by field. Plus the next run times, so you can see before deploying whether the schedule really does what you meant. All locally in your browser.

The five fields of a cron expression

A classic crontab entry consists of five space-separated fields, always in this order:minute (0–59), hour (0–23), day of month(1–31), month (1–12) and day of week (0–6, where 0 is Sunday – 7 is also accepted as a second name for Sunday).

┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12)
│ │ │ │ ┌─ day of week (0–6, Sunday = 0)
│ │ │ │ │
* * * * *

Each field accepts four notations: * for “every value”, a list (1,15,30), a range (1-5) and a step (*/15 for every 15 units, 1-9/2 for every second value within a range). The month and day-of-week fields also understand the English short names JAN–DEC andSUN–SAT.

The day-of-month and day-of-week trap

By far the most common cron misunderstanding: 0 0 1 * MON does not run on the first Monday of the month. When both day fields are restricted, cron combines them withOR – the job runs on every 1st of the month and additionally on every Monday. Only if one of the two fields is * does the other one alone decide. This tool points that out explicitly as soon as an expression walks into the trap.

The @ shorthands

Vixie cron provides abbreviations for the usual rhythms: @yearly (=@annually, equal to 0 0 1 1 *), @monthly,@weekly, @daily (= @midnight) and @hourly.@reboot is a special case: it is not a schedule but an event – the job runs once when the cron daemon starts, which is why there can be no “next run times” for it.

Where the same expression means something else

The five fields are identical in crontab, GitHub Actions andKubernetes CronJobs, so an expression carries over. Two differences still matter: GitHub Actions always works in UTC, and on Kubernetes it depends on the optional timeZone field. A 0 3 * * * therefore does not necessarily fire at three o'clock local time.

The Quartz scheduler from the Java world uses six or seven fields instead – with seconds up front and an optional year at the end – and adds special characters such asL (last day), W (nearest weekday) and # (nth weekday of the month). This tool deliberately implements the classic five-field syntax and rejects Quartz extensions with an error rather than silently misreading them.

Frequently asked questions

Which time zone are the listed runs in?
Your browser's – it is named above the list. On the target system its own time zone applies, and that is exactly where the classic “the job ran an hour early” comes from. When in doubt, check timedatectl on the server or the timeZone field of your CronJob.

Why do some expressions produce no runs at all?
Because there are none. 0 0 30 2 * asks for 30 February – a date that never occurs. The search looks five years ahead; if it finds nothing in that window, the tool says so explicitly instead of showing an empty list.

What exactly does */15 mean?
“Every 15th value, starting at the lowest” – in the minute field that is 0, 15, 30 and 45. Importantly, the step always refers to the field's range, not to the time elapsed since the last run. */40 in the minute field therefore yields 0 and 40 followed by a 20-minute gap, rather than an even 40-minute rhythm.

Is my input uploaded?
No. Parsing, plain-text translation and run-time calculation are plain JavaScript in your browser – there is no server that could receive anything. The only things remembered are whether you last used read or build mode and how many runs you want listed.