Cron Expression Generator
Build a cron schedule, see when it runs, and get the config for it.
Loading the cron builder…
About the Cron Expression Generator converter
Cron syntax is five small fields that are easy to write and surprisingly easy to get wrong — and a schedule that is wrong usually looks fine until the job runs at three in the morning on the wrong day.
Build the expression here, read it back in plain English, check the next five times it would actually fire, and take away the configuration for wherever you are running it.
The two day fields are ORed, not ANDed
This is the single most common cron bug. When both day-of-month and day-of-week are restricted, cron runs the job when <em>either</em> matches. So `0 0 13 * 5` is the 13th of every month <em>and</em> every Friday — it is not Friday the 13th.
When one of the two fields is `*`, the fields behave as you would expect. This tool flags the case explicitly whenever you restrict both, because nothing in the syntax hints at it.
See it fire before you deploy it
The next five run times are calculated from the expression rather than approximated, including the awkward cases: months without a 31st are skipped, and 29 February only appears in leap years.
An expression can be perfectly valid and still never run — `0 0 30 2 *` asks for 30 February. That is reported as never running rather than left as a blank list you might mistake for a bug in the page.
Config for where it actually runs
The same schedule is generated for crontab, Kubernetes CronJob, GitHub Actions, node-cron, Python APScheduler and Spring `@Scheduled`, with the surrounding boilerplate each one needs.
The field count is adapted per target, because they disagree: Spring wants six fields with seconds first, APScheduler's `from_crontab` wants five. When dropping a seconds field would change the schedule, the tool says so instead of quietly halving the interval.
Time zones are where schedules go wrong
GitHub Actions and Kubernetes both interpret expressions as UTC by default. A job written for 09:00 local will fire at the wrong hour, and the gap changes twice a year with daylight saving.
The next-run list can be shown in either UTC or your own zone so you can see the difference, and each generated config carries a note about which zone that scheduler assumes.
Frequently asked questions
What do the five fields mean?
In order: minute, hour, day of month, month, day of week. A sixth field, if present, goes at the front and means seconds — used by Spring, Quartz and node-cron but not by crontab.
How do I write "every 15 minutes"?
`*/15 * * * *`. The slash is a step: */15 in the minute field means 0, 15, 30 and 45. `0,15,30,45 * * * *` is the same schedule written out.
Is Sunday 0 or 7?
Both. The day-of-week field accepts 0 to 7 with Sunday at each end, and names such as SUN and MON work too. This tool normalises 7 to 0 so you never see Sunday listed twice.
Why is my GitHub Actions schedule running late?
Scheduled workflows are queued on shared infrastructure and can be delayed, especially on the hour when everyone else has scheduled theirs. Pick an odd minute rather than 0 if timing matters. They are also disabled after 60 days of repository inactivity.
Does it support L, W and # from Quartz?
Not yet — those are Quartz extensions rather than standard cron, and most schedulers reject them. A `?` is accepted and treated as `*`, so pasting a Quartz expression usually still works.
Is my expression sent anywhere?
No. Parsing, the next-run calculation and the code generation all happen in your browser. Nothing is uploaded, and the page keeps working offline.