Cron Expression Builder

Cron is the oldest scheduling DSL still in production use. Vixie cron — the implementation almost every modern cron daemon descends from — was first shipped in 1987. The 5-field syntax (minute, hour, day-of-month, month, day-of-week) is identical in standard Unix cron, in GitHub Actions workflows, in Kubernetes CronJob, in Vercel Cron Jobs, in AWS EventBridge schedule expressions, in Cloudflare Workers cron triggers, and in essentially every job scheduler that took the easy path of "the syntax developers already know." Knowing how to read and write cron is non-optional infrastructure literacy.

The hard part is not the basic syntax — `0 0 * * *` for midnight is easy to memorize — but the corner cases. **Step expressions** (`*/5` for every five minutes) work in most places but have wraparound rules that surprise people. **Combined ranges and steps** (`0-30/5` for every five minutes during the first half of each hour) are powerful but rarely understood. **Day-of-month and day-of-week interaction** is the worst corner — when both are restricted, cron uses OR semantics (`1st of the month OR Sunday`), which is the opposite of what most people guess. **Time zones** are not part of the cron spec at all; the daemon's host zone decides, and getting that wrong is how schedules quietly fire at the wrong hour.

This tool gives you a live translator. The plain-English description comes from **`cronstrue`** — the most-deployed cron-description library, used internally by Hangfire, Quartz, and many cron UIs. It handles the awkward cases gracefully: `0 */2 * * *` becomes "Every 2 hours", `30 9 1-7 * MON` becomes "At 09:30 AM, between day 1 and 7 of the month, and only on Monday", and an invalid expression produces an error pointing at the field that failed. The description updates as you type, so you can verify your intent immediately rather than waiting for a job to fire (or not fire) in production.

Below the description, the **Next 5 fire times** panel uses a small custom evaluator (not cronstrue, which only describes) to step forward from the current moment and find the next five times the expression matches. This is what catches the most common cron mistakes:

- Wrote `0 0 * * 7` thinking 7 was a missing day? Next fire is correct (Sunday) because 7 normalizes to 0, but the panel makes it obvious. - Forgot that `30 9 *` doesn't mean "9:30 once a day" — the day-of-month default `*` means "every day" so it actually fires daily at 9:30 AM. - Wrote `0 9 1 * 1` thinking "9 AM on the 1st AND Mondays" — actually means "9 AM on the 1st OR Mondays" per cron's day-field OR rule, so the panel will show non-consecutive fires.

The time zone displayed above the fire-time list is your browser's local zone, detected from `Intl`. Be careful: **cron daemons in production usually run in UTC or the host's zone, not your zone**. GitHub Actions, AWS EventBridge, and most modern cloud schedulers use UTC by default. Older Linux systems use the system's configured zone. Kubernetes CronJob defaults to the cluster zone. Always verify your target scheduler's zone before deploying a schedule. The fire-time panel here is for *intuition* — match it against your scheduler's zone when you copy the expression.

The **presets** below the description cover the eleven schedules most teams actually use: every minute (testing only — please do not deploy this), every 5 minutes, every 15 minutes, hourly, daily at midnight, daily at 9 AM, weekly on Sunday midnight, weekdays at 9 AM, monthly on the 1st, quarterly, and yearly. Click any preset to jump there; this is faster than typing the expression and reduces the risk of off-by-one mistakes (writing `*/30 * * * *` instead of `*/30 * * * 0-6` and accidentally including or excluding weekends).

A note on **what this does not support**. The `@`-prefix shortcuts — `@daily`, `@hourly`, `@reboot` — are commonly accepted by Unix cron but are not part of any spec and are not understood by GitHub Actions or Kubernetes CronJob. The Quartz extensions (`L` for last day of month, `W` for nearest weekday, `#` for nth occurrence of a weekday) are Quartz-specific. The 6-field (seconds) and 7-field (year) variants used by some Java-based schedulers are also not supported. This tool sticks to the canonical 5-field syntax that works in the largest number of schedulers.

Everything runs in your browser. `cronstrue` is ~30 KB compressed; the next-fire-time evaluator is a few hundred lines of pure TypeScript with vitest coverage including the OR-semantics edge case. No network requests during description or fire-time computation — your scheduled jobs' expressions stay in your tab.