Cron Expression Parser

How To Use

1. Pick a dialect that matches your scheduler. The default is cron-parser, but you can switch to Standard, Spring, Quartz, or Hangfire/NCrontab — the same expression is then read the way that framework reads it.
2. Type or paste a cron expression. 5 fields are always minute hour day-of-month month day-of-week; 6 / 7 fields add seconds or a trailing year depending on the dialect (see the table below).
3. Click Parse to decode the expression. You get a place to switch dialects, a plain-English summary, a line for each field, a timezone selector (UTC by default, and the run times recompute when it changes), and the next 10 execution times in the selected zone.
4. Click Copy next times to copy the execution list to your clipboard.
5. If the expression is invalid, a clear error tells you which field and value are wrong.

Dialects and Field Layouts

Different schedulers interpret cron differently, most confusingly the day-of-week numbering and whether the 6th field is a leading second or a trailing year. This tool normalizes everything to one internal model, so the computed times and the plain-English description are always correct for the dialect you selected.

The day-of-week offset is the most common source of bugs: the same token 1-5 means Monday–Friday in Standard/Spring/Hangfire, but Sunday–Thursday in Quartz (where 1 is Sunday). This tool applies that offset for you automatically.

Cron Every N Minutes Cheat Sheet (and Other Frequencies)

The step syntax */N is the same across dialects, so these expressions work in Linux crontab, Spring, Quartz, and Hangfire alike. Copy the row you need and verify the next run times above.

One subtlety worth knowing: */5 divides the field's range starting from its minimum, so it always fires on multiples of 5 from :00 — it does not mean "5 minutes after each previous run". For an offset grid like :02, :07, :12, write 2-59/5 * * * *.

The Same Daily Time in Every Dialect

The classic migration bug: an expression copied from one scheduler into another silently shifts meaning. "Daily at 09:30" is written three different ways — and in Quartz the day-of-week digits move too:

Rules of thumb: Spring, Quartz, and Hangfire put a leading 0 seconds field in front; Quartz needs ? in one of the two day fields and numbers weekdays from Sunday; Standard cron has no seconds at all. Paste both sides into the parser with the right dialect selected and the computed run times confirm the equivalence — or expose the shift.

Usage Example

With the default cron-parser dialect, 0 9 * * 1-5 means “at 09:00, Monday through Friday”. Select the Quartz dialect and the same five fields read as a leading minute/hour with day-of-week 1-5 = Sunday–Thursday.

Trying */5 * * * * returns the summary “Every 5 minutes” followed by ten run times spaced exactly five minutes apart. Because the computation is local and deterministic, you can rely on the output being immediate and consistent across runs.

Frequently Asked Questions

What is cron syntax?

Cron syntax uses five fields — minute, hour, day of month, month, and day of week — to describe a recurring schedule. A crontab expression such as 0 9 * * 1-5 means "at 09:00 every weekday", and this tool turns any cron schedule into plain English, no matter the dialect.

What is the difference between 5-field and 6-field cron expressions?

The standard grammar has five fields: minute, hour, day of month, month, and day of week. The meaning of an extra sixth field depends on the dialect: in cron-parser (the default) a sixth trailing field limits the schedule to a single year — for example 0 9 * * 1-5 2027 runs every weekday at 09:00 only during 2027. In Spring, Quartz, and Hangfire/NCrontab, a sixth field is a leading second — 0 30 9 * * * runs at 09:30:00. Quartz additionally supports a seventh trailing year field: 0 0 9 * * 1-5 2027.

Why is Quartz’s day-of-week different?

Quartz numbers days of the week 1–7 where 1 is Sunday and 7 is Saturday. Most other flavors use 0–7 where 0 (or 7) is Sunday. So 1-5 means Monday–Friday in Standard/Spring/Hangfire but Sunday–Thursday in Quartz. This tool applies the correct mapping for the dialect you pick, so descriptions and computed times are always right.

What is @daily?

@daily is a shortcut meaning 0 0 * * * — once per day at midnight (00:00). Dialects that support seconds expand it to 0 0 0 * * * (seconds = 0). The parser also understands @hourly, @weekly, @monthly, and @yearly (and @annually), and expands them before decoding.

Why can't some Daily time sets be expressed as one expression?

The Daily preset lets you add several time points at once, but cron's minute and hour fields are independent, so a single expression can only represent the full Cartesian product of your minutes and hours. For example, wanting 09:00 and 18:30 would need minutes {0,30} and hours {9,18}, which would also run at 09:30 and 18:00 — times you didn't intend. When your time points don't form that complete minute×hour set, the generator reports that they can't be expressed as a single expression. Either pick points that form a complete combination, or use the Custom input (or multiple expressions) for irregular schedules.

When do ? and L matter?

In cron, * means "every value" in a field, while ? is an alternative used in the day-of-month or day-of-week fields to mean "no specific value". Here ? is treated as * for convenience. The L marker (last day of the month, e.g. 0 0 0 L * ?) is Quartz-only and is preserved in the field-by-field output.

Why only the next 10 run times?

Ten upcoming executions are enough to validate a schedule and spot mistakes without drowning in a long list. For minute-level schedules the sequence repeats predictably, so a short window is all you need. The times shown are the next ten strictly after the current moment.

What timezone is used?

By default all computation is done in UTC, and the output is labeled with the zone actually used. A Timezone selector (next to the dialect) evaluates the schedule in any listed IANA zone instead — the run times recompute immediately when you change it. The choice is not saved anywhere: every visit starts from UTC, so the same expression and zone always produce the same run times.

Is my expression uploaded to a server?

No. Everything runs locally in your browser. Your cron expression never leaves your device — there is no network request and no backend, so it is safe to paste sensitive or internal schedules.