Cron Next-Run-Time Calculator
Paste any 5-field cron expression and see the next 10 times it will actually fire, in UTC — the fastest way to confirm an expression does what you think it does before you save it and find out three weeks later that it's been running at the wrong time, or not at all.
Supports the syntax you'll actually encounter
*— every value- Ranges —
1-5 - Lists —
1,3,5, and lists of ranges —1-5,10,20-25 - Steps —
*/15(every 15 units), or10-40/5(every 5th value within a range)
The field everyone eventually gets wrong: day-of-month and day-of-week together
When both the day-of-month and day-of-week fields are restricted (neither is *), standard cron treats them as OR, not AND — the job runs if either condition is true, not only when both are. 0 0 1 * 1 doesn't mean "the 1st of the month, but only if it's also a Monday" — it means "midnight on the 1st of the month, OR midnight every Monday," which is usually not what someone intended when they wrote it. This calculator implements that exact real-world semantic (verified against known cron behavior), not a simplified version — so if your next-run list looks like it's firing far more often than expected, this OR behavior on those two fields together is the first thing to check.
Why UTC, and what that means for you
This calculates against UTC because that's what most cron daemons and scheduled-job platforms actually run in by default — AWS EventBridge, most Docker cron containers, and plenty of Linux servers unless explicitly configured otherwise. If your actual scheduler runs in local time instead, convert the times shown here to your timezone before trusting them, and double-check which convention the specific system you're deploying to actually follows — assuming UTC when the system is actually local time (or vice versa) is a very easy, very common mistake.
Where this earns its keep
Sanity-checking a cron expression before it goes into a production crontab, Kubernetes CronJob, or CI scheduled pipeline; debugging "why did this job run twice today" by checking whether a DOM/DOW OR condition is silently doubling up matches; or just confirming a step expression like */17 lines up with the interval you actually meant, since minute 0 plus every 17 minutes does not evenly divide the hour and drifts across hour boundaries in a way that surprises people the first time they see it.