Cron Expression Parser

A cron expression is a compact schedule made of five fields — minute, hour, day-of-month, month, and day-of-week — that tells a scheduler when to run a job. The syntax is terse and easy to misread, and a wrong field can mean a backup that never runs or a job that fires every minute. This parser translates an expression into plain English and lists the next run times so you can confirm the schedule does what you intended before it ships.

Reading the five fields. Each field accepts a value, a list (1,15), a range (1-5), a step (*/15), or * for "every". 0 9 * * 1-5 means "at minute 0 of hour 9, every day-of-month, every month, on weekdays Monday–Friday" — i.e. 9:00 AM on business days. */15 * * * * runs every fifteen minutes. Month and day-of-week also accept names (JAN, MON). Convenience macros like @daily and @hourly expand to their five-field equivalents.

The day-of-month / day-of-week trap. This is the single most misunderstood corner of cron. When both the day-of-month and day-of-week fields are restricted (neither is *), most cron implementations run the job when either matches — not both. So 0 0 13 * 5 fires on the 13th of the month and on every Friday, not only on Friday the 13th. This parser applies that OR rule, which is why the next-run list may surprise you if you expected an AND.

How you'll use it. Paste an expression to see it described and to preview when it will actually run. It is ideal for reviewing a crontab in a pull request, sanity-checking a CI schedule, or debugging why a job ran at an unexpected time. The run times are computed in UTC; a real scheduler uses the server's local timezone, so account for the offset — the epoch converter helps you line a predicted run up against a UTC log timestamp.

Common mistakes. Confusing the field order (minute comes first, not hour), forgetting that day-of-week 0 and 7 both mean Sunday, and assuming six-field (seconds-first) Quartz syntax works everywhere — standard Unix/Vixie cron is five fields, which is what this parser expects.

Defensive and operational angle. Schedules are security-relevant: a certificate-renewal or log-rotation job that silently stops running becomes an incident weeks later. Verify the human-readable description matches intent, monitor that scheduled jobs actually complete (dead-man's-switch alerting), and avoid overly frequent schedules that can mask abuse or exhaust resources.