Cron expression parser — offline

Cron syntax is famously easy to get wrong and easy to misread. Five terse fields decide whether a job runs every fifteen minutes or once a year, and the difference between a correct expression and an expensive mistake is often a single character. Paste one here and you get a plain-English description plus the next five run times, so you can confirm the schedule matches your intent before it ships.

Parsing and the schedule preview run entirely in your browser. Nothing is transmitted — the site has no backend, and a Content-Security-Policy blocks third-party requests. That matters more than it first appears: cron expressions usually arrive pasted from a deployment config alongside job names and internal service references.

Standard cron is five fields — minute, hour, day of month, month, day of week — and an optional leading sixth field for seconds is also accepted. Shortcuts like */15 for step values and ranges such as 1-5 work as expected.

Two things catch people out repeatedly. The first is that day-of-month and day-of-week are ORed, not ANDed: if both are restricted, the job runs when either matches, so an expression meant to fire only on a Monday the 1st will in fact fire every Monday and every 1st. The second is the classic * * * * * — a wildcard in every field means every minute, which is the single most common way to accidentally hammer a system.

Reading the plain-English description back is the fastest way to catch both. If it does not say what you meant, the expression is wrong regardless of how right it looks.

The next five run times are shown in your browser's local timezone, which is what you actually want when sanity-checking whether a schedule fires at a sensible hour. Concrete dates catch mistakes that a description alone can hide — a job you believed ran nightly showing its next five runs a month apart is unambiguous.

Remember that the machine running the job may not share your timezone. Servers commonly run in UTC, so a schedule that reads as 9am locally can fire in the middle of your night in production. Daylight saving adds a further wrinkle: in timezones that observe it, jobs scheduled in the changeover hour can be skipped or repeated. Where timing genuinely matters, run cron in UTC and reason about it there.

Related and equally local: Unix timestamp converter for the instants themselves.