Cron syntax is one of those formats that everyone has used and almost no one has fully memorized. Five fields, each with its own range and conventions, and at least three different gotchas (day-of-month vs day-of-week semantics, named months and weekdays, the step modifier). This builder takes a cron expression, validates it, describes what it actually does in plain English, and shows the next 5 dates it will fire — so you can verify intent before pasting into a scheduler config.
The 5 fields
* * * * *
│ │ │ │ │
│ │ │ │ └── day of week 0-6 or sun-sat (0 = Sunday)
│ │ │ └────── month 1-12 or jan-dec
│ │ └────────── day of month 1-31
│ └────────────── hour 0-23
└────────────────── minute 0-59Each field accepts:
*— wildcard, matches every valid value5— specific value1-5— range (inclusive)1,3,5— explicit list*/15— step from the field’s minimum (every 15 units)0-30/10— step within a range
For month and day-of-week, you can use names: jan, feb, …, dec; sun, mon, …, sat. Case-insensitive.
The day-of-month vs day-of-week trap
When both day-of-month and day-of-week are restricted (neither is *), the schedule fires on a date that matches either one. Not the intersection — the union.
0 12 1,15 * 1This fires at noon on the 1st of any month, OR the 15th of any month, OR every Monday — not just on Mondays that happen to be the 1st or 15th. To restrict to a specific day-of-week within specific dates, you need a script-side check; pure cron can’t express AND for these two fields.
When only one of them is restricted, that one is the gate. 0 9 * * 1 fires at 9 AM every Monday only.
Aliases
The standard aliases all expand to canonical 5-field expressions:
@yearly/@annually→0 0 1 1 *(Jan 1, midnight)@monthly→0 0 1 * *(1st of every month, midnight)@weekly→0 0 * * 0(Sundays, midnight)@daily/@midnight→0 0 * * *(every day, midnight)@hourly→0 * * * *(every hour at :00)
Example: nightly database backup
You want a backup to run every night at 2:30 AM. Try 30 2 * * *. Description: “At 02:30, every day”. Next 5 runs: tomorrow 02:30, the day after 02:30, etc. Looks right — paste into crontab.
Example: weekday business-hours health check
A health check every 15 minutes during weekday business hours (9 AM-5 PM, Mon-Fri). Try */15 9-17 * * 1-5. Description includes “every 15 minutes”, “during 09:00-17:00”, “Monday through Friday”. Next runs verify it skips weekends.
Example: monthly billing report
First of the month at 6 AM. Try 0 6 1 * *. Description: “At 06:00, on the 1st”. Next runs: 1st of next month, 1st of the following month, etc. Confirmed.
Common mistakes
Confusing day-of-week numbering. Sunday is 0 (not 7) in standard cron, though 7 is also accepted (it normalises to 0). Monday is 1. Some systems (Quartz) use 1-7 with Sunday=1 — that’s a different dialect, not standard cron.
Forgetting that */N starts at the field’s minimum. */15 in the hour field is 0, 15, 30, 45 — but the hour field’s max is 23, so this is actually 0, 15 only. To run every 6 hours, use */6, not */15. To run on a specific irregular pattern, use a list.
Expecting day-of-month and day-of-week to AND. They OR when both are restricted. To express “Mondays in January”, restrict the month: 0 9 * 1 1 — fires every Monday in January, since both being restricted gives OR. Wait, that’s still OR — so this actually fires every Monday OR every January day. To get true intersection, you need post-processing in your script.
Pasting Quartz syntax. Quartz adds a seconds field at the start: 0 0 9 * * ?. That’s 6 fields, not 5 — this tool will reject it. Use a Quartz-specific tool or remove the seconds field if you’re targeting standard cron.
What this tool does not do
It does not support Quartz extensions: L (last day of month), W (nearest weekday), # (nth weekday), ? (no specific value). Those are Quartz-only.
It does not support the optional 6th seconds field. Standard cron has 5 fields; some schedulers extend it. Stay in 5-field territory unless you specifically need the extension and your scheduler supports it.
It does not validate against your timezone. Cron schedules run in the timezone of the system that runs them — typically UTC for cloud schedulers, local time for crontab. The next-runs calculator uses your browser’s local timezone.
It does not save expressions. Use the URL bar or paste into your scheduler config to persist. For the timezone side of scheduling (converting a local “Tuesday 9am” into UTC before writing the cron), the timezone converter handles the shift.