Question 1

What are the five fields in a standard cron expression, in order?

Accepted Answer

A standard cron expression has five space-separated fields, in this exact 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 and 7 is also accepted as Sunday by Vixie cron). So `0 9 * * 1` reads as: at minute 0, hour 9, every day-of-month, every month, but only on day-of-week 1 (Monday) — i.e. 09:00 every Monday. The most common mistake is reversing day-of-month and day-of-week, or assuming the first field is the hour. This validator labels each field explicitly so you can see exactly what each token expands to before you deploy.

Question 2

What does the day-of-month / day-of-week OR rule mean, and why does it surprise people?

Accepted Answer

This is the single most counter-intuitive rule in cron. When BOTH the day-of-month and the day-of-week fields are restricted (neither is `*`), a job runs when EITHER field matches — not both. The man 5 crontab page states it directly: 'if both fields are restricted (i.e., aren't *), the command will be run when either field matches.' So `0 0 1 * 1` does NOT mean 'midnight on the 1st, but only if it's a Monday.' It means 'midnight on the 1st of the month, AND midnight on every Monday.' If you actually want 'the 1st only when it's a Monday,' standard cron cannot express that in one line — you have to add a guard inside the script (e.g. check `date +%u` is 1). When one of the two fields is `*`, only the other field constrains the day, and the OR rule does not apply. This calculator's next-run output applies the OR rule exactly as Vixie cron does, so you can see the real firing schedule rather than the one you assumed.

Question 3

What does `*/15` mean, and how is it different from `15`?

Accepted Answer

`*/15` in the minute field means 'every 15th minute starting from 0' — it expands to 0, 15, 30, 45. The `*/n` form is a step over the whole field range, so a job with `*/15 * * * *` runs four times an hour. A bare `15` means only minute 15 — the job runs once an hour, at :15. A common edge case: `*/15` does not guarantee an even spacing if the field range is not a multiple of the step. In the minute field (0-59) `*/20` gives 0, 20, 40 — there is no run at minute 60 because the field caps at 59, so the gap between :40 and the next :00 is 20 minutes anyway. But `*/40` gives only 0 and 40, then jumps back to 0 — a 20-minute gap followed by a 40-minute gap. Always expand the step and look at the actual value set, which this validator shows in the field breakdown.

Question 4

Does this tool use UTC or my local timezone?

Accepted Answer

Everything here is computed in UTC. The cron fields are matched against UTC wall-clock components (UTC minute, hour, day, month, day-of-week), and the next-run times are shown as ISO-8601 UTC timestamps ending in Z. This is deliberate: the calculation is deterministic and reproducible regardless of where you or your server are located. Real cron daemons, by contrast, run in the timezone of the crontab's owner (or the `CRON_TZ` / `TZ` variable). The production-grade pattern is to run your servers in UTC and write your cron expressions in UTC, which sidesteps the Daylight Saving Time trap entirely — a job scheduled for `0 2 * * *` in a DST-observing timezone either skips the 2 a.m. hour in spring or runs twice in fall. UTC has no DST transitions, so the schedule is unambiguous. GitHub Actions schedules are always UTC for the same reason.

Question 5

Why is this 5-field cron and not the 6-field or 7-field Quartz syntax?

Accepted Answer

This validator implements the standard POSIX / Vixie 5-field cron only: minute, hour, day-of-month, month, day-of-week. It does not parse the Quartz dialect used in Java/Spring, which prepends a seconds field (6 fields) and can append a year field (7 fields), nor does it support Quartz/EventBridge special characters like `?` (no specific value), `L` (last), `W` (nearest weekday), or `#` (nth occurrence). Standard cron — used by Linux crontab, Kubernetes CronJob, and GitHub Actions — has 1-minute resolution and no concept of seconds, last-day-of-month, or nth-weekday. If your platform is Quartz or AWS EventBridge, the field positions and special characters differ, and you should validate against that platform's own documentation. Keeping this tool to the 5-field standard means the next-run math is exactly the POSIX behavior, with no dialect ambiguity.

Question 6

Can I use `7` for Sunday, and how do named days fit in?

Accepted Answer

Yes — in the day-of-week field, both `0` and `7` mean Sunday. The POSIX range is 0-6 (0 = Sunday through 6 = Saturday), but Vixie cron also accepts `7` as a Sunday alias to accommodate older conventions and avoid breaking existing crontabs. This validator normalizes `7` to `0` internally, so `0 0 * * 7` and `0 0 * * 0` produce the identical schedule. Many real cron daemons additionally accept three-letter day and month names (SUN, MON, JAN, FEB, etc.), which remove the off-by-one ambiguity entirely. This tool sticks to numeric fields for the standard 5-field grammar; if you write named days, convert them to numbers first (SUN=0, MON=1, … SAT=6 for days; JAN=1 … DEC=12 for months).

Question 7

Why does my monthly job on the 31st sometimes not run?

Accepted Answer

Because not every month has a 31st. An expression like `0 0 31 * *` schedules midnight on the 31st of every month, but February (28 or 29 days) and the 30-day months (April, June, September, November) have no 31st — so cron simply does not fire those months. Cron never 'rolls over' to the next valid day; if the day-of-month is out of range for the current month, the job is skipped. This validator surfaces this directly: enter `0 0 30 2 *` (February 30, which never exists) and the next-run search returns an error after scanning a 5-year horizon, because there is no matching instant. For a reliable monthly job, use `0 0 1 * *` (the 1st always exists) or `0 0 28 * *` (the 28th always exists), or move end-of-month logic into a script that checks whether tomorrow is the 1st.

Question 8

How are the next 5 run times computed, and are they stable?

Accepted Answer

The scheduler does a minute-granular forward scan. Cron has 1-minute resolution, so the engine starts at the whole minute strictly after the reference instant, zeroes the seconds and milliseconds, and walks forward one minute at a time, testing each candidate minute against the expanded field sets (with the day-of-month/day-of-week OR rule applied). The first five candidates that match are returned. The reference instant is the page-load time (`Date.now()`), passed in explicitly — the underlying engine never reads the clock itself, so the same expression and the same reference instant always produce the same answer. That determinism is why the math is testable and why a shared result URL reproduces exactly. The forward scan is capped at a 5-year horizon; if nothing matches in that window (an impossible date like February 30), the tool reports that the expression may never fire rather than looping forever.

Field	Range	Allowed values
Minute	0-59	0
Hour	0-23	9
Day of month	1-31	every value
Month	1-12	every value
Day of week	0-6 (0=Sun)	Mon

Cron Expression Builder & Validator

What this means

Worked example

Frequently asked questions

Show the algorithm