Free Online Crontab Validator & Explainer
Validate cron expressions instantly. Get a plain-English description and the next 5 run times in any timezone. Free, 100% client-side.
100% Client-Side · Your data never leaves your browserHow to Use Crontab Validator & Explainer
Type or paste your cron expression into the input field. The tool validates it in real time as you type — no need to click a button to see immediate feedback.
- A Valid / Invalid badge updates instantly next to the input.
- A human-readable description appears below when the expression is valid (e.g. "Every 5 minutes").
- The next 5 execution times are listed in the selected timezone.
Use the Timezone selector to display run times in any major timezone. Click any badge in the Common Expressions panel to load a pre-built expression into the input. Press Ctrl/Cmd+K to clear everything.
Frequently Asked Questions
What is the difference between this crontab validator and the cron generator?
The cron generator is a visual builder — it helps you construct a new cron expression from scratch using field inputs and a dropdown of examples. The crontab validator is focused on checking an expression you already have: it immediately tells you whether the expression is syntactically valid, explains it in plain English, and shows the next 5 scheduled run times in any timezone.
Does cron use 5 fields or 6 fields?
Standard Unix/Linux crontab uses 5 fields: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–7, where both 0 and 7 represent Sunday). Some job schedulers such as Quartz (Java) and AWS EventBridge add a seconds field as the first token, giving 6 fields. This tool validates the standard 5-field format.
What special characters are supported?
* means "every value". , separates a list of values (e.g. 1,3,5). - defines a range (e.g. 1-5). / defines a step (e.g. */15 means every 15 units). L means "last" in day fields. W means "nearest weekday". # means "nth weekday of the month" (e.g. 2#3 = third Tuesday).
How does timezone handling work?
The next-run times are calculated using the timezone you select. By default UTC is used. Switching to a local timezone (e.g. America/New_York) shows the times adjusted for that zone, including any DST offsets. The underlying cron expression itself is timezone-agnostic — the timezone only affects how the run times are displayed.
Why do some valid-looking expressions show an error?
Some expressions are syntactically plausible but logically impossible. For example, 0 0 31 2 * (midnight on February 31) will never run because February never has 31 days. The validator reports these as parse errors rather than silently ignoring them.
Can I use named months and day abbreviations?
Yes. You can use three-letter month names (JAN through DEC) and weekday names (SUN through SAT) in place of numbers. For example, 0 9 * * MON-FRI is equivalent to 0 9 * * 1-5.