About Cron Expression Builder
Cron Expression Builder turns the five (or six) cryptic fields of a cron schedule into something you can read and edit visually. Pick days, months, hours and minutes from dropdowns and the expression updates live; or paste an existing schedule and see it explained in plain English plus the next few times it will fire. Validates against both standard Unix cron and the extended Quartz/AWS variants. Handy for setting up cron jobs, GitHub Actions schedules, Kubernetes CronJobs, and AWS EventBridge rules without second-guessing the syntax.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Build with the visual editor
Select minute, hour, day-of-month, month, and day-of-week ranges from grid pickers. The expression in the output box updates as you click.
- 2
Or paste an expression
Drop in something like '0 9 * * 1-5' and the builder reverse-engineers the picker, shows a sentence description ('At 09:00 on weekdays'), and validates each field.
- 3
Preview the next runs
A list of the next 5–10 trigger times is calculated against your local timezone, so you can sanity-check that 'every other Tuesday at 3am' really means what you think.
The five fields, left to right
A standard Unix cron line is five space-separated fields, and the entire syntax follows from knowing their order and ranges. Read them left to right: minute, hour, day-of-month, month, day-of-week.
| Position | Field | Allowed values |
|---|---|---|
| 1 | Minute | 0–59 |
| 2 | Hour | 0–23 (24-hour clock, no AM/PM) |
| 3 | Day of month | 1–31 |
| 4 | Month | 1–12 (or JAN–DEC) |
| 5 | Day of week | 0–7 (0 and 7 both = Sunday, or SUN–SAT) |
So 30 9 * * 1-5 is 'minute 30, hour 9, any day-of-month, any month, Monday–Friday' — i.e. 09:30 on weekdays. An asterisk means 'every value of this field'.
Step and range syntax, where most mistakes hide
- */15 in the minute field means 'every 15 minutes' (0, 15, 30, 45) — a step, not 'at minute 15'. New users routinely write 15 when they mean */15.
- A range like 9-17 in the hour field is inclusive on both ends — that's nine hours (9 through 17), not eight.
- Steps combine with ranges: 0-30/10 means 0, 10, 20, 30. Bare */10 means every 10th value across the whole field's range.
- Lists use commas: 0 9,12,17 * * * fires at exactly three times a day. Don't confuse 9,12,17 (three specific hours) with 9-17 (every hour in between).
- * * * * * is every single minute — a very common accident when someone meant 0 * * * * (once an hour, on the hour).
The day-of-month / day-of-week OR trap
This is the single most misunderstood rule in cron, and it bites experienced people. When both the day-of-month (field 3) and the day-of-week (field 5) are restricted — neither is * — cron treats them as OR, not AND. So 0 0 13 * 5 does not mean 'midnight on Friday the 13th'. It means 'midnight on the 13th of every month, AND every Friday' — far more often than you intended. To get a true 'Friday the 13th' you have to restrict one field and test the other in the job's own logic, because plain cron simply can't express the AND. The standard behaviour traces back to the original Vixie cron implementation that nearly every modern cron inherits.
The everyday version of this trap: 0 0 1 * 1 looks like 'first Monday' but actually fires on the 1st of every month and on every Monday. If you want a specific weekday-of-month, the Quartz-style # token (1#1 = first Monday) is the tool — and many schedulers support it.
Timezone is the bug you find in production
Cron has no timezone field. A schedule fires in whatever timezone the host is configured for, and that's where 'it ran at the wrong time' comes from. The classic case is GitHub Actions, which always runs scheduled workflows in UTC regardless of your repository or account settings — so 0 9 * * * is 09:00 UTC, which is the middle of the night in the Americas. AWS EventBridge lets you pin a timezone; a bare crontab uses the server's local time, which may differ from your laptop's. Two further sharp edges: during daylight-saving transitions a 02:30 job can run twice or not at all on the changeover day, and the preview here is computed in your browser's local timezone for readability, so mentally apply the offset to your deployment target. When in doubt, schedule in UTC everywhere and convert for humans with the world clock. The visual cron guide walks through more worked examples.
Related guides
All guidesFrequently asked questions about Cron Expression Builder
Does it support Quartz / AWS / Spring cron extensions?
Yes — toggle six-field mode for a seconds column (Spring, Quartz, AWS EventBridge), and special tokens like @yearly, @hourly, L (last day of month), W (nearest weekday) and # (nth weekday) are recognised. Standard Unix five-field cron is the default since it covers the most common use cases — crontab, Kubernetes CronJob, GitHub Actions.
Why does the next-run preview not match my server?
Cron schedules run in whichever timezone the host is configured for. The preview uses your browser's local timezone for readability — if your server runs in UTC, set your machine to UTC temporarily or mentally apply the offset. GitHub Actions, for example, always fires in UTC.
Will it warn me about a schedule that never fires?
Yes — combinations like 'Feb 31' or 'day-of-month=30 AND day-of-week=Sun (every year forever)' are flagged. The validator also points out commonly mistaken patterns, like using '* * * * *' (every minute) when you meant '0 * * * *' (top of every hour).
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.