What this tool does
This is a free, browser-only cron expression explainer and builder. Paste any standard 5-field cron expression, or a 6-field one with a leading seconds field, and it parses every field, tells you in plain English what schedule it describes, and lists the next run times computed from the current moment in your device's own timezone. If you would rather not memorize cron syntax at all, the visual builder below lets you pick each field's behavior from dropdowns — every value, a fixed step, a range, or specific values — and it emits a ready-to-use expression you can copy straight into crontab, GitHub Actions, Kubernetes CronJobs, AWS EventBridge or any scheduler that speaks standard cron syntax.
How to use it
Type or paste a cron expression into the box at the top and click Explain (or just start typing — it re-parses automatically). The plain-English panel updates immediately, and the "Next runs" panel lists the upcoming execution times, each one computed from your local clock. Invalid expressions — wrong field count, an out-of-range value, or a malformed range — show a specific error message instead of a silent wrong answer. To build an expression from scratch, use the visual builder: choose a mode (Every / Every N / Range / Specific) for each field, tick "Include seconds" if you need sub-minute precision, and click "Use this expression" to load the result into the box above.
Example 1 — a weekday business-hours reminder
Input
*/15 9-17 * * 1-5
Output — plain English
Every 15 minutes, hours 9 through 17, on Monday through Friday.
Output — next runs (example, local time)
2026-07-13 09:00 (Mon) 2026-07-13 09:15 (Mon) 2026-07-13 09:30 (Mon) 2026-07-13 09:45 (Mon) 2026-07-13 10:00 (Mon)
Read left to right: */15 in the minute field fires every quarter hour, 9-17 restricts that to the 9am-5pm window, and 1-5 in the weekday field limits it to Monday (1) through Friday (5) — the classic "every 15 minutes during business hours, weekdays only" job.
Example 2 — a monthly report at midnight on the 1st, or every Monday
Input
0 0 1 * MON
Output — plain English
At 00:00, on day 1 of the month, or on Monday.
Output — next runs (example, local time)
2026-07-13 00:00 (Mon) 2026-07-20 00:00 (Mon) 2026-07-27 00:00 (Mon) 2026-08-01 00:00 (Sat) 2026-08-03 00:00 (Mon)
This one trips people up: because BOTH day-of-month (1) and day-of-week (MON) are restricted, standard cron combines them with OR, not AND. The job runs on every Monday AND on the 1st of every month — notice 2026-08-01 is a Saturday, and it still fires because it's the 1st. If you actually wanted "only the 1st, and only if it's a Monday," you would need application-level logic; cron itself cannot express that intersection.
Cron field reference
| Field | Allowed values | Allowed syntax | Position (5-field) | Position (6-field) |
|---|---|---|---|---|
| Second | 0-59 | * , - / | (not present) | 1st |
| Minute | 0-59 | * , - / | 1st | 2nd |
| Hour | 0-23 | * , - / | 2nd | 3rd |
| Day of month | 1-31 | * , - / | 3rd | 4th |
| Month | 1-12 or JAN-DEC | * , - / | 4th | 5th |
| Day of week | 0-7 or SUN-SAT (0 and 7 = Sunday) | * , - / | 5th | 6th |
* means "every value." A comma list like 1,15,30 means "these exact values." A range like 9-17 means "every value from 9 through 17 inclusive." A step like */15 means "every 15th value starting from the field's minimum," and a stepped range like 10-20/2 means "every 2nd value from 10 through 20." These can combine in a comma list, e.g. 0,30,*/10.
FAQ
What do the 5 fields in a cron expression mean?
A standard cron expression has 5 space-separated fields in this order: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC), and day of week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). Each field can be a wildcard (*), a single value, a comma-separated list (1,15,30), a range (9-17), a step (*/15), or a combination like a stepped range (10-20/2).
What does the optional 6th seconds field mean, and where does it go?
When you provide 6 fields, this tool follows the convention used by node-cron, croner and most JavaScript cron libraries: the seconds field comes FIRST, followed by the usual minute, hour, day-of-month, month and day-of-week fields. So */30 * * * * * means every 30 seconds. This differs from Quartz Java syntax, which also puts seconds first but adds a required year field at the end; that extra year field is not supported here.
How does this tool handle day-of-month AND day-of-week both being restricted?
It follows standard Vixie-cron (Linux crontab) semantics: if BOTH the day-of-month and day-of-week fields are restricted (neither is *), the schedule runs when EITHER condition is true, not when both are true. For example 0 0 1 * MON runs at midnight on the 1st of every month, OR every Monday — not only on Mondays that happen to be the 1st. If only one of the two fields is restricted, only that field matters, which is the intuitive behavior most people expect.
Are the next run times shown in UTC or my local time?
Your browser's local timezone, using its own clock and DST rules — the same way cron itself evaluates schedules on the machine it runs on. The tool never sends your input anywhere, so there is no server-side timezone to worry about; what you see is computed by your own device's clock.
Can this detect a cron expression that can never actually run?
Yes. Expressions like 0 0 31 2 * (February 31st, which never exists) are syntactically valid — every field is within range — but the date they describe never occurs on any calendar. The next-run search scans forward up to roughly 11 years of calendar days; if nothing matches in that window, the tool reports zero upcoming runs so you can catch the mistake before deploying it.
Does the visual builder support every cron syntax feature?
The builder covers the features behind the vast majority of real-world schedules: every value, a fixed step (every N), a range, and an explicit list of values, for each field including optional seconds. It does not emit non-standard Quartz-only characters like L (last day), W (nearest weekday) or # (nth weekday of month) — you can still type those directly into the expression box, but the plain-English explanation and next-run calculator do not interpret them.