Cron Expression Generator & Explainer
Paste a 5-field cron expression to get a plain-English explanation, a field-by-field breakdown, and its next 5 scheduled run times.
Runs at minute(s) 0, 15, 30, 45 of every hour of every day.
Field breakdown
| Field | Expression | Matches |
|---|---|---|
| Minute | */15 | 4 value(s) |
| Hour | * | 24 value(s) |
| Day of month | * | 31 value(s) |
| Month | * | 12 value(s) |
| Day of week | * | 7 value(s) |
Next 5 runs (your local time)
About this tool
How to use it
- Paste a standard 5-field cron expression (minute hour day-of-month month day-of-week) into the input, or pick one of the common-schedule presets.
- Read the plain-English sentence above the table — it updates live as you type or edit the expression.
- Check the field breakdown table to see exactly what each of the 5 fields matched, and how many values each one expands to.
- Check the next 5 run times below, computed from your device's current local time and time zone.
Why it matters
Cron syntax packs a lot of meaning into five terse fields, and it's easy to misread a range, a step value, or the day-of-month/day-of-week interaction (they're combined with OR, not AND, when both are restricted — a detail that trips up even experienced engineers). Seeing the plain-English sentence and the actual next few run times catches a misconfigured schedule before it ships to a cron job, a CI pipeline, or a Kubernetes CronJob.
When to use it
Double-checking a cron expression before adding it to crontab, a CI/CD schedule, or a CronJob manifest. Understanding an existing schedule someone else wrote without a comment. Verifying that a day-of-month-and-day-of-week combination behaves the way you expect (this is the single most common cron mistake).
Good to know
Supports the standard 5-field POSIX cron syntax: exact values, ranges (a-b), steps (*/n and a-b/n), and comma-separated lists, for all five fields. Day-of-week accepts both 0 and 7 for Sunday. Does not support 6-field cron variants with a seconds field, non-standard macros like @daily/@hourly, or named months/weekdays (JAN, MON, etc.) — only numeric fields, matching the original POSIX cron specification most schedulers still follow. Next-run times are computed against your browser's local clock and time zone, which may differ from the time zone the actual cron daemon runs in — always confirm the server's configured time zone separately.
Common questions
Why does day-of-month AND day-of-week both being restricted give more matches than I expected?
Standard cron treats day-of-month and day-of-week as an OR when both are restricted (not left as *) — a schedule runs if EITHER condition is true, not only when both match. This is the single most common source of surprise in cron schedules, and the tool calls it out explicitly whenever it applies.
Does this support @daily, @hourly, or other cron shorthand macros?
No — only the standard 5-field numeric syntax. Convert a macro to its numeric equivalent first (@daily is 0 0 * * *, @hourly is 0 * * * *, and so on).
Why are the 'next run' times different from what my server actually runs?
The next-run calculation uses your browser's local time zone, not the server's. If your cron daemon runs in UTC (common for servers) and you're viewing this in a different time zone, the wall-clock times will differ even though the underlying schedule is identical.
Is my cron expression sent anywhere?
No. Parsing, explaining, and computing next-run times all happen with plain JavaScript in your browser tab — nothing is uploaded or logged.
What if it says 'no matching run found in the next 4 years'?
That means the search window (capped for performance) didn't find a match — almost always because of an impossible day-of-month-and-month combination, like day-of-month 31 restricted to April, June, September, or November, none of which have a 31st.