Cron Expression Builder

You want a job to run every weekday at 7:30 AM but skip the first of the month. The cron expression is `30 7 2-31 * 1-5` — and writing that from scratch is how typos make it into production. Build it visually, see the resulting expression, and confirm the next 5 run times look right before deploying.

The builder handles the standard 5-field cron format (minute, hour, day of month, month, day of week) and the extended 6-field form some schedulers use (with seconds). Operators (lists, ranges, steps, the `*` and `?` wildcards) are all supported.

Following the next-run-time preview is the fastest way to catch errors. If you intended 'every weekday' and the preview shows it running on Saturdays, the expression is wrong.

The standard cron format has five fields: minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–6 or 7, where 0 and 7 both mean Sunday). Some systems add a 6th field for seconds at the front. Each field accepts a single value, a list (`1,3,5`), a range (`1-5`), a step (`*/15` meaning every 15 units), or any combination. The wildcard `*` means 'every value.'

A worked example: 'every weekday at 7:30 AM' is `30 7 * * 1-5`. Breaking it down: minute 30, hour 7, any day of month, any month, days of week Mon–Fri (1 through 5). Adding 'except the 1st of the month' makes it more complex. Cron uses OR between day-of-month and day-of-week, which is unintuitive — `30 7 2-31 * 1-5` means 'minute 30, hour 7, day-of-month 2–31, OR day-of-week 1–5,' which would still trigger on the 1st if it's a weekday because the OR makes the day-of-week match enough. To get AND behavior, you need `*` in one of the day fields and the constraint in the other, then handle the exception in the script itself.

The non-intuitive behavior of day-of-month and day-of-week as OR rather than AND is the single most common cron bug. `0 9 15 * 1` doesn't mean 'the 15th if it's a Monday' — it means 'every 15th OR every Monday at 9 AM,' which fires roughly 15+ times per month instead of once. To get 'the 15th only if Monday,' use `*` for day-of-month and check the date inside your script. Quartz cron (used by Java schedulers) and AWS EventBridge support a 'last' specifier (`L`) and other extensions that make some of these queries cleaner; standard cron does not.

Time zone handling varies by scheduler. Linux `cron` uses the server's local timezone — which is whatever the system clock is set to. AWS EventBridge defaults to UTC. Vercel cron defaults to UTC. GCP Cloud Scheduler lets you specify the timezone explicitly. If your job fires at the wrong hour after deployment, the timezone is the first thing to check. The builder shows the next 5 expected run times in your local timezone, which catches most timezone confusion before you push to production.

For sub-minute scheduling, standard cron does not support it — the finest granularity is one minute. If you need to run something every 30 seconds, you need a daemon, a queue, or a scheduler like systemd timers that supports sub-minute intervals. Trying to fake sub-minute with cron (running every minute and sleeping internally) works but introduces clock-drift issues across long uptimes. Use the right tool for the granularity.