Cron Expression Explainer

How this works

Cron syntax is compact by design, which makes it fast to write and easy to misread. This tool parses the expression the way a real scheduler would — including ranges, steps, lists, and named months or weekdays — and shows both what it means and, more usefully, when it will actually fire next. The time zone toggle exists because the single most common cron bug isn't a syntax error, it's a job that's perfectly correct and running exactly on schedule — just in a time zone nobody expected.

FAQ

Why does the same expression run at a different time in UTC vs my time zone?

A cron expression has no time zone of its own — it's just five numbers. What time they land at depends entirely on what clock the system running the job is set to. crontab uses the server's local time, GitHub Actions and most managed schedulers default to UTC, and some let you set a time zone explicitly. If your job runs at an unexpected hour, this is almost always why.

What do the five fields mean, in order?

Minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). "*/15 9-17 * * 1-5", for example, reads as: every 15 minutes, between 9am and 5pm, every day, every month, Monday through Friday.

Can I use names like MON or JAN?

Yes — three-letter month and weekday names (JAN-DEC, SUN-SAT) work as aliases for their numeric values, and this tool accepts either.

What does an error here usually mean?

Almost always a typo: a sixth field (some systems add seconds — this tool expects the standard five), a value out of range for that field, or a stray character. The error message names which part failed to parse.