Cron Expression Parser

In order: minute (0–59), hour (0–23, 24-hour clock), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday — 7 is also accepted as Sunday, matching most real cron implementations). Each field accepts *, meaning "every valid value"; a single number; a range like 1-5; a comma-separated list like 1,15,30; and a step like */15 (every 15 units, starting from the field's minimum) or 1-31/2 (every 2nd value within that range).

By brute force: starting from the next full minute, this tool checks every single minute against your expression, one at a time, until it finds 5 matches. It's deliberately not clever — no jumping ahead to "the next plausible minute" — because a simple check-every-minute loop is easy to verify correct and easy to trust. To keep that loop from running forever on an expression that can never match (like a February 30th), the scan is capped at 2,000,000 minutes, a little under 4 years — past that point you'll see an honest "no match found in the next ~4 years" instead of a spinner that never resolves.

This is the one place this tool deliberately simplifies real cron behavior, and it's worth stating plainly: this tool requires ALL FIVE fields to match (AND logic) for every candidate minute. Real crontab implementations (Vixie cron and most of its descendants) switch to OR logic specifically between day-of-month and day-of-week whenever BOTH are restricted from "*" — so 0 0 15 * 1 in real cron means "midnight on the 15th, OR any Monday", not "midnight on a Monday that's also the 15th". This tool computes the second, stricter reading in that specific case. If you only restrict one of the two (leaving the other as *), both approaches agree, so this only matters when you've deliberately set both fields.

No — this tool parses the standard 5-field form only (minute hour day month weekday), the form documented by POSIX cron and supported everywhere. It doesn't expand shorthand strings like @daily, @hourly, or @reboot, and it doesn't support the 6-field seconds-precision variant some newer schedulers (like Quartz) use. If your scheduler accepts one of those, translate it to the plain 5-field form first — @daily is 0 0 * * *, for example.

Whatever you pick in the timezone dropdown above the results — it defaults to UTC on this page, since that's the safest assumption for a cron job running on a server whose local timezone you may not control. Change it to see the same expression's run times as they'd land in a different zone; the underlying minutes being checked don't change, only how they're displayed and which local wall-clock they're matched against.

No. Parsing and every run-time calculation happen entirely in your browser with plain JavaScript — nothing you type is sent to a server, logged, or stored. That's true for every tool on this site.