Crontab Explainer
Translate a crontab expression into human-readable schedule and list the next 10 scheduled runs.
min hour dom month dow (5-field) or sec min hour dom month dow (6-field).
—
—
Quick reference
*— every unit*/5— every 5th,— list (e.g.1,3,5)-— range (e.g.1-5)- Dow: 0/7 = Sun, 1 = Mon, … 6 = Sat
About Crontab Explainer
A crontab expression describes a repeating schedule with five whitespace-separated fields: minute, hour, day of month, month, and day of week, with a sixth field adding seconds in some implementations. Wildcards, lists, ranges, and step values let you express anything from a nightly backup to a quarterly report run. This explainer parses the expression, shows what each field means, and lists the next ten times the job will fire.
Use it when you are troubleshooting scheduled jobs: jobs that never run, run at the wrong time, or run more often than expected are usually explained by a subtle field mistake. Note that cron interprets times in the local timezone of the daemon rather than the user's, and on most systems there is no per-job timezone field without extensions like CRON_TZ. Also remember that shorthands such as @daily, @hourly, or @reboot are convenience strings supported by cronie and Vixie cron, not part of the standard five-field format.
Field-by-field, with your tokens echoed back
The human-readable panel is not a sentence — it is a labelled echo of the tokens you typed, one line per field, which makes an off-by-one shift easy to spot after a six-field expression gets reinterpreted. Arity is strict: anything other than five or six whitespace-separated tokens throws `Need 5 or 6 fields`, so `@daily` and `@hourly` are rejected outright rather than expanded into their numeric equivalents.
Parsing is bound to the `input` event, so the panel and the run list recompute on every keystroke — no button press, and no way to rest on a half-typed expression without watching it flicker through parse errors. The sample button drops in `0 9 * * 1-5`, the weekday-morning schedule that most real crontab mistakes actually resemble.
Ranges, steps, and name tables
Both day-of-week and month have name tables of three-letter lowercase abbreviations. Because the range branch resolves both endpoints through those tables, `mon-fri` and `jan-mar` work here in a way they do not in several other parsers, as do bare `mon` and `jan`. A name that is not in the table is reported instead of silently resolving to -1, so a typo produces a note rather than an empty run list.
Steps apply to an explicit start and end, which means `5/10` without a range means the single value 5 rather than 5, 15, 25. Reversed ranges and invalid steps are reported rather than quietly producing an empty field.
A weekday value of 7 is Sunday: it is normalised to 0 before matching, because JavaScript's `getDay()` never returns 7. Both spellings are listed in the quick reference below.
The seconds field and how failures are reported
In six-field mode the seconds field is part of the match, so a `*/10` cadence produces times ten seconds apart rather than whichever second the walk happened to land on. When a field cannot match any real date the minute-by-minute walk is skipped entirely and the run panel says so explicitly; an empty list is no longer indistinguishable from a broken page.
Frequently Asked Questions
How do I validate a cron expression?
What cron format is supported?
Is my data sent to a server?
Do I need an account or API key?
Can I use these tools offline?
All processing happens in your browser. No uploads, no tracking, no servers. Your API keys, configs, and private payloads stay private — 100% client-side.