About this cron tool

Why it exists

Cron syntax is compact, forty years old and full of quiet traps. The fields look like intervals but behave like filters. Steps reset at field boundaries rather than continuing across them. Sunday is both 0 and 7. And when you restrict both the day-of-month and day-of-week fields, the daemon combines them with OR instead of AND — a rule that surprises even experienced engineers and that a surprising number of online cron parsers implement incorrectly.

The most reliable way to check a schedule is not to read the expression but to look at the actual timestamps it produces. That is what this tool is built around: type or assemble an expression, and see the next five moments it will fire, in your time zone and in UTC side by side.

What it implements

Standard five-field cron as understood by Vixie cron, which is the implementation behind cron on Debian, Ubuntu, Red Hat and most other Linux distributions, and the syntax adopted by Kubernetes CronJob, GitHub Actions and the major cloud schedulers.

• Wildcards (*), single values, lists (1,3,5), ranges (1-5) and steps over both the full field (*/5) and a range (10-30/5).
• Month names JAN–DEC and day names SUN–SAT, case-insensitive.
• Day-of-week values 0 through 7, with 0 and 7 both meaning Sunday.
• The shorthands @hourly, @daily, @midnight, @weekly, @monthly, @yearly and @annually.
• The day-of-month / day-of-week OR rule, applied exactly as Vixie cron applies it.

Deliberately not implemented: seconds and year fields, and the Quartz special characters L, W and #. Pasting one of those produces a clear error rather than a plausible-looking wrong answer.

How the next runs are computed

Each field is expanded into the explicit set of values it matches. The calculator then steps forward one calendar day at a time from the current minute, checking the month and the day rules for that date, and for matching days walks the hour and minute sets in ascending order. Days are anchored at midday internally so that daylight-saving transitions can never cause a calendar day to be skipped or visited twice.

The scan is capped at roughly four years of days. That bound is what makes an impossible expression such as 0 0 30 2 * return "no upcoming runs" in a few milliseconds instead of locking up the browser.

Privacy and cost

Everything runs client-side. No expression you type is transmitted, logged or stored — a production schedule you paste in here goes no further than the tab it is typed into. There is no account and nothing to sign up for. The parser and the next-run calculation need nothing from the network, so the tool keeps working fully offline once the page has loaded.

The site is free to use. It may carry advertising to cover hosting; see the privacy policy for what that would mean.

Corrections

If you find a schedule this tool explains incorrectly, or a run time that disagrees with your daemon, that is a bug worth reporting. Please include the exact expression and what you expected. The contact page has the address.