Paste a 5-field crontab expression and get a plain-English explanation of every field, a combined summary and the next 10 runs in your local timezone.
All parsing happens locally in your browser. Nothing leaves your device.
A crontab line has exactly five whitespace-separated fields, and the cron daemon checks them once per minute: if minute, hour, day-of-month, month and day-of-week all accept the current minute, the command runs. This parser validates every token, expands wildcards, ranges, steps and lists into concrete value sets, explains each field in words, and then fast-forwards through real browser time to list the next ten minutes that match — so the schedule you read is the schedule your machine will execute, in your timezone.
*. When both are restricted, a run happens if EITHER matches: 0 0 13 * 5 fires every Friday AND every 13th — not "Friday the 13th". This tool follows that classic rule and flags it under the summary so the result never surprises you.*/15 means every 15 units from the field minimum, 10-18/2 every 2 units inside a range, and a/N from a value N onward to the end of the range. Commas build lists (1,15,30), and list entries may mix any of these forms in the same field.Different schedulers speak slightly different dialects. This tool implements classic five-field Vixie cron — exactly what the crontab(5) man page and the cron daemon inside most Docker images use. Frameworks like Spring and Quartz prefix a seconds field (six or seven fields total) and add extra tokens, so an expression written for them can mean something different — or fail to parse at all. Paste the five-field form and the predictions here match a stock Linux crontab.
Both. The day-of-week field accepts 0 through 7, and 7 is normalized to 0, so either number means Sunday. You can also write the English names sun through sat, in any case, including in ranges like mon-fri.
The next-run list is built by stepping through local time in your browser's timezone, which is an approximation of how real cron behaves. Around a spring-forward gap, a job scheduled inside the skipped hour typically does not run that night, and around a fall-back it may run once — but daemons differ. For jobs where the exact minute matters, schedule in UTC or avoid the one or two hours around each transition.
No. Those are Quartz/Spring extensions (last day of month, nearest weekday, nth weekday of the month), not classic cron, and the tool shows an error rather than guessing. Express the same idea with plain fields — for example 0 0 29-31 2 * plus a guard in your script approximates monthly runs on the last February day.
No. Parsing the expression and iterating the next ten run times are a few lines of vanilla JavaScript running in your browser. Your expression never leaves your device, and there is no account, no tracking and no network request involved.
If you just finished with Cron Expression Parser, the natural next steps are curl to JavaScript, UUID Generator, UUID v7 Generator, or browse every tool in Daily Tools.