Cron Expression Builder

Why cron expressions are worth building visually, not memorizing

A cron expression packs five decisions into a 9–13 character string, and every field means something different depending on position. Get one field wrong — put an hour value where a day-of-month value belongs — and the job either doesn’t run, runs constantly, or runs at 3 a.m. on the wrong day. None of that shows up until the schedule actually misfires, which is usually the worst possible time to find out.

This builder keeps each field separate and readable while you work, then assembles the final string and tells you, in plain language, what it will actually do — plus the next five real timestamps it will trigger, calculated in your local time. That last part matters more than most builders admit: 0 9 * * 1 reads as “9am on Monday,” but whether that’s 9am in your timezone or the server’s is exactly the kind of detail that causes production incidents.

How the five fields work together

Cron reads left to right as minute, hour, day-of-month, month, and day-of-week. The part people trip on most is the interaction between day-of-month and day-of-week: if you restrict both at once (say, 15 for day-of-month and 1 for day-of-week), cron doesn’t require both conditions — it fires when either one matches. That’s an OR, not an AND, and it’s the single most common source of “why did this run twice” bug reports in scheduled-job history.

Reading the syntax

• * — every possible value for that field.
• */n — every nth value starting from the field’s minimum.
• a-b — an inclusive range from a to b.
• a,b,c — an explicit list of values.
• a-b/n — every nth value within a range.

Common mistakes this tool catches before deploy

Two of the most frequent scheduling errors are using * where a specific value was intended (which silently turns a “once a day” job into an every-minute job), and forgetting that most cron implementations accept both 0 and 7 for Sunday — leading teams to define the same job twice, thinking they’ve covered two different days. The next-run preview above exists specifically to surface both before they reach a crontab file, a CI scheduler, or a cloud function’s trigger config.

Where this differs from server cron behavior

Standard Unix cron and most managed schedulers (GitHub Actions, AWS EventBridge, Kubernetes CronJobs) share this five-field format and the OR-logic behavior described above. A few platforms — Quartz being the best-known example — use a six- or seven-field format with a separate seconds field and different day-of-week numbering. If you’re targeting Quartz, treat this builder’s output as the standard five-field baseline and adjust field count accordingly; the underlying logic for ranges, steps, and lists carries over directly.