Cron Expression Parser

How it works

The parser splits your expression into its 5 fields and expands each one into an explicit set of allowed values: */15 in the minute field becomes the set {0, 15, 30, 45}, 1-5 in day-of-week becomes {1, 2, 3, 4, 5}, and lists like 1,3,5 are unioned together. Every value is range-checked as it's expanded, which is why a typo like 61 * * * * fails immediately with a message naming the exact field and the range it expected, instead of silently producing a schedule that never fires.

The "next 5 runs" list is computed by brute force, and that's a feature: starting from the next whole minute, the code steps forward one minute at a time (up to a year, about 527,000 checks, which takes a few milliseconds) and tests each candidate minute against the expanded sets. A useful side effect of simulating instead of calculating: expressions that are syntactically valid but can never fire, like 0 0 30 2 * (February 30th), aren't an error, they just come back with "no matching run found in the next year". If you see that message, your expression parses fine but describes a date that doesn't exist or is more than a year away.

All date math uses the browser's Date object in your local time zone, and it all runs in this page's JavaScript. Check DevTools' Network tab: no request is made when you type an expression, so nothing about your infrastructure's schedules leaves your machine.