Cron Tester
Descriptions of cron expressions are easy to agree with and easy to be wrong about. This gives you the dates instead — the next fire times in the zone the scheduler runs in, so you can check the schedule against what you meant.
Output appears here as you type.
Runs entirely in your browser. Nothing you paste here is uploaded or stored.
Questions
Does anything get sent anywhere?
No. Both tools are pure functions in your tab, using the time zone database your browser already ships. The page cannot open a network connection — its Content-Security-Policy sets connect-src to ‘none’.
What is the day-of-month and day-of-week rule?
When both fields are restricted, cron fires when EITHER matches — not both. "0 0 1 * MON" runs on the first of every month AND on every Monday, which is usually far more often than the author intended. When one field is a wildcard, only the other applies. It is the most commonly misread rule in cron, which is why this lists dates rather than describing the expression.
Why does it matter whether a local time is ambiguous?
Because twice a year a wall-clock reading is either missing or doubled. When clocks go forward, 02:30 simply does not occur — a job scheduled then may not run at all. When they go back, 01:30 occurs twice, and a job scheduled then may run twice. Both are real outages that get diagnosed as flaky infrastructure, and neither is visible in a converter that quietly picks one instant.
It says my expression never fires.
Then it genuinely never does. "0 0 30 2 *" is valid syntax for the thirtieth of February, and "0 0 31 4 *" for the thirty-first of April. Both parse cleanly and neither will ever run — a bug no linter catches and no description reveals.
Are seconds and special characters supported?
Not yet. The five standard fields, names such as MON and JAN, ranges, lists, steps, ? as a wildcard and the @-shorthands all work. Quartz extensions — a leading seconds field, L, W, # — do not, and a six-field expression is reported as such rather than misread.