Cron Parser
Parse 5/6-field cron expressions into plain-language descriptions and upcoming run times, with range validation.
>_ USAGE GUIDE
Paste a cron expression (5-field or 6-field) and get two things immediately: a plain-language description of when the job runs, and a list of the next actual execution times. The workflow is deliberately reversed: read the translation first to confirm semantics, then check the run-time list against your intent — two checkpoints against writing a wrong schedule.
- Paste the expression: both 5-field crontab and 6-field formats with a seconds field are supported
- Read the description: an "every day at 08:00" style summary confirms what you wrote
- Check upcoming runs: the next executions verify the schedule behaves as expected
- Fix flagged fields: out-of-range values (minutes 0–59, months 1–12) are called out on the spot
Field-range validation catches typos before your scheduler does — a 61st minute or a 13th month is flagged the moment you paste, not discovered days later when a job silently never fires. Parsing runs locally with zero network requests, handy when configuring jobs or answering "why did this task run at a weird time?".
>_ FAQ
Q1 · What does the cron expression 0 0 * * * mean?
The five fields are minute, hour, day-of-month, month, and day-of-week. With minute 0 and hour 0 and the rest as wildcards, it means every day at 00:00. Other frequent patterns: */5 * * * * every 5 minutes, 0 9 * * 1-5 weekdays at 9 a.m., 0 0 1 * * midnight on the 1st of each month. Paste any uncertain expression here to see its description and next run times.
Q2 · Why is my cron job not running as expected?
Check by likelihood: a miswritten expression — translate it here first (the classic mistake is mixing up how day-of-month and day-of-week combine); time zones — the server runs UTC while you wrote the schedule in local time, an 8-hour gap; or the task system skipping runs after a restart or while the previous run was still going. Translate the expression first, then check the server clock with date.
Q3 · What happens when both day-of-month and day-of-week are set?
This is cron's most counter-intuitive rule: when both fields are restricted (neither is *), they combine as OR — the job runs if either matches. So 0 0 1 * 1 fires on the 1st of the month *or* every Monday, not "the 1st when it is also a Monday". To express just one condition, leave the other field as *.
Q4 · How do the crontab, Spring, and Quartz dialects differ?
Three main gaps: field count — crontab has 5 fields (min hr dom mon dow), Spring prepends seconds for 6, Quartz takes 6 or 7 (appending a year, 1970–2099); the no-value marker — Quartz uses ? to leave day-of-month or day-of-week unspecified (the two are mutually exclusive, one must be ?), while Spring rejects ? entirely (use *); weekday numbering — crontab/Spring count 0/7 as Sunday and 1 as Monday, Quartz counts 1 as Sunday and 7 as Saturday (MON-style names mean the same in both). Quartz also adds L (last day), W (nearest weekday) and # (nth weekday). This tool lets you switch dialects at the top and parses and previews under the selected semantics.
Q5 · Can cron express intervals like "every 90 minutes"?
Not precisely. Cron matches calendar fields: */90 in the minute field is interpreted as minutes 0 and 30, which behaves like every 30 minutes aligned to the clock. True arbitrary intervals need a scheduler's duration syntax (such as Spring's fixedDelay) or custom logic. Cron is built for calendar moments — daily at some time, weekly on some day — not for uniform elapsed intervals.