Cron Parser

Reading a cron expression

Cron is the original Unix scheduler, dating to the late 1970s, and the scheduling syntax it inherited has spread to every job runner since: GitHub Actions, Kubernetes CronJobs, AWS EventBridge, Vercel cron, the lot. The expression is five fields separated by spaces:

minute  hour  day-of-month  month  day-of-week

Each field accepts a number, a range, a list, a wildcard, or a step. Together they describe a recurring time pattern. 0 9 * * 1-5 means "minute 0 of hour 9, any day, any month, weekdays only" — 9am Monday through Friday.

Paste an expression into the form above and the tool translates it to plain English and previews the next several runs based on your local time.

Field reference

• Minute: 0–59
• Hour: 0–23 (24-hour clock; midnight is 0)
• Day of month: 1–31
• Month: 1–12 (or JAN–DEC)
• Day of week: 0–6 (or SUN–SAT; Sunday is 0, Monday is 1)

Operators

• * — every value. * * * * * means every minute.
• 5 — that exact value.
• 1-5 — range, inclusive.
• 1,15,30 — list.
• */10 — step. */10 in the minute field means every 10 minutes (0, 10, 20, 30, 40, 50). 0/15 is the same idea: starting at 0, every 15 minutes.

Common patterns

• 0 * * * * — top of every hour
• */5 * * * * — every 5 minutes
• 0 0 * * * — daily at midnight
• 0 9 * * 1-5 — weekdays at 9am
• 0 0 1 * * — first of every month at midnight
• 0 0 * * 0 — every Sunday at midnight
• 0 0 1 1 * — New Year's Day at midnight
• 15 14 1 * * — 2:15pm on the first of every month

Things that bite

Day-of-month and day-of-week together

If you set both, classic cron treats it as or: the job runs when either matches. 0 0 1 * 0 runs on the 1st of every month and every Sunday, not on the 1st only when it's a Sunday. To get the AND behavior you have to handle it in code.

Time zone

Classic Unix cron runs in the system time zone, which on a server is usually UTC. Hosted scheduler products (AWS, GitHub) almost always run in UTC by default. A "9am" cron in UTC is 4am or 5am for most US users — this trips up most teams at least once. Either set the schedule in UTC explicitly, or use the time-zone option some systems provide.

DST and missing/duplicate times

If you schedule a job for 2:30am local time and the clocks spring forward, that minute doesn't exist that day — depending on the cron implementation, the job runs immediately at 3am, gets skipped, or both. In the fall, 2:30am happens twice. Most modern schedulers run jobs in UTC to sidestep this entirely.

Six-field expressions

Some systems — Quartz, AWS EventBridge — add a seconds field at the start and a year field at the end, making expressions six or seven fields. If your cron string has more than five fields, you're not in classic-cron territory. This tool parses the standard five-field form.

What cron is not great at

Cron is fine for "every Monday at 9am." It's awful for "30 seconds after this other job finishes," "only on the third Tuesday of the month," or "with retry on failure." For workflows like that, reach for a real job orchestrator (Temporal, Airflow, dbt) instead of trying to encode complex logic in cron expressions.