The five fields, left to right

A standard cron expression is minute (0-59), hour (0-23), day-of-month (1-31), month (1-12), and day-of-week (0-6, where both 0 and 7 mean Sunday depending on implementation). Each field accepts a literal value, a `*` wildcard meaning "every value," a range (`1-5`), a list (`1,3,5`), a step (`*/15` meaning every 15 units), or a combination like `10-40/10`. Reading left to right in order of granularity — minute, then hour, then the two day fields, then month — makes it easier to mentally parse an unfamiliar expression than jumping around.

The day-of-month / day-of-week OR trap

This is the single most common cron misunderstanding: when both the day-of-month and day-of-week fields are restricted (neither is `*`), most cron implementations — including the one this tool follows — treat them as an OR, not an AND. `0 0 15 * 1` doesn't mean "the 15th, if it's also a Monday" — it means "midnight on the 15th of every month, AND every Monday at midnight," which fires far more often than most people expect when they first write an expression like that. If you actually want an AND relationship (only the 15th when it falls on a Monday), that has to be handled outside cron itself, typically by having the job check the date and exit early on a mismatch.

When "no upcoming runs" is the correct answer

This tool searches up to two simulated years of minutes looking for the next 5 matches before giving up. If it comes back empty, the expression is very likely impossible to satisfy rather than something this tool failed to compute — the classic case is `0 0 30 2 *` (the 30th of February), which can never occur on the Gregorian calendar no matter how far forward you search. Seeing this result is a useful signal to double check the day-of-month and month fields for a typo before assuming the tool is broken.