Cron expression generator — and a reader that tells you what yours already does
Build a standard five-field cron line from plain controls, or paste one you inherited and get it back as an English sentence with the next eight run times in a time zone you choose. This page implements standard Unix cron — minute, hour, day-of-month, month, day-of-week — and where Quartz, Spring or Jenkins differ it names the difference instead of quietly guessing at it. Nothing is uploaded or saved.
- Nothing is uploaded or saved
- Works offline
Standard five-field Unix cron — the syntax Vixie cron, crond, Kubernetes CronJobs and GitHub Actions all take. Quartz’s six-field form with a leading seconds field, its L / W / # / ? tokens, and the Jenkins H are recognised by name and reported — never evaluated.
At 09:30, on Monday, Tuesday, Wednesday, Thursday and Friday.
| Field | Written | Means |
|---|---|---|
| Minute | 30 | 30 |
| Hour | 9 | 9 |
| Day of month | * | every day of the month |
| Month | * | every month |
| Day of week | 1-5 | Monday, Tuesday, Wednesday, Thursday, Friday |
Reading the clock and your time zone…
How it works
- 1
Paste the line you already have
Most people arrive holding an expression rather than needing a new one. Drop it in the box and the page reads it back as a sentence, breaks it into a field-by-field table, and lists the next runs. If it cannot be read, you get a sentence naming the field and the token — not “invalid expression”.
- 2
Or build it field by field
Each of the five fields has three modes: every value, every Nth value, or a specific set you pick from chips. The controls write into the expression box, and the expression box is the only copy of the schedule — so there is no second list to drift out of step with the first, and pasting something the chips cannot represent simply switches that field to “written by hand”.
- 3
Check the next run times, in your zone
Cron matches against the local wall clock of the machine running it, so “next run” is meaningless without a zone. The picker starts on the one your browser reports and lists every zone it knows; the gap between consecutive runs is printed beside each row, which is how an uneven schedule gives itself away at a glance.
- 4
Read the two day fields carefully
Day-of-month and day-of-week are the one place standard cron does something almost nobody expects. When both are set, it runs when either matches. The reader says so in the sentence, and the run list proves it — try the “The 13th — or Friday?” preset.
- 5
Copy it into your crontab
The expression is five fields and a space; your command goes after it on the same line. Nothing here is written to your machine and nothing is sent from it — the parser, the calendar arithmetic and the clock all run in this page.
Frequently asked questions
Which cron does this page implement?
Standard five-field Unix cron — the syntax of Vixie cron and its descendants, which is what a Kubernetes CronJob and a GitHub Actions schedule also take. The fields are minute, hour, day-of-month, month, day-of-week. It expands the @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly shorthands, and recognises @reboot as having no schedule at all. It does not evaluate Quartz, Spring or Jenkins syntax; it identifies them and says so.
Why is my six-field expression rejected, and what about “5/15”?
Both are Quartz, the Java scheduler behind a great many “cron” configuration fields including Spring’s @Scheduled. Quartz puts a seconds field in front, so its six fields are second, minute, hour, day-of-month, month, day-of-week, with an optional seventh for the year; standard cron has no seconds field and cannot run more often than once a minute. Quartz also reads “5/15” as “from 5 to the end of the field, every 15”, which standard cron does not accept — the standard spelling is “5-59/15”, selecting 5, 20, 35 and 50. Paste either form here and you are told which dialect it is and how to write the same thing in standard cron, rather than getting a syntax error.
Is “0 0 13 * 5” Friday the 13th?
No, and this is the single most misunderstood rule in cron. When day-of-month and day-of-week are both restricted, standard cron runs when either one matches — not both. So “0 0 13 * 5” fires at midnight on the 13th of every month, and also at midnight on every Friday. In a typical month that is five or six runs, not zero or one. Paste it above and read the run list. When one of the two fields is “*”, the rule does not apply and the other field decides on its own. Standard cron genuinely cannot express “Friday the 13th”; the usual answer is a daily job whose script checks the date and exits early.
Do 0 and 7 both mean Sunday?
In Vixie cron, yes. The day-of-week field accepts 0 through 7, with both ends meaning Sunday, which is why “0 0 * * 7” and “0 0 * * 0” produce identical run lists above. That also makes “5-7” a legal way to write Friday, Saturday and Sunday. Not every parser is as generous — some accept only 0 — so 0 is the safer of the two to write down. Three-letter names work as well: SUN, MON, TUE, WED, THU, FRI, SAT, and JAN through DEC in the month field.
Why is “*/40 * * * *” not every 40 minutes?
Because a step is a filter over the field’s own range, not a timer counting from the last run. The minute field runs 0–59, so “*/40” selects minute 0 and minute 40 and stops — 80 is past the end. The job then runs at :00 and :40 of every hour: a 40-minute gap, then a 20-minute gap, forever. Load the “Every 40 minutes?” preset and the gap column above shows it directly. Steps only come out even when they divide the field cleanly: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 and 30 for minutes.
What time zone do the run times use?
The one shown in the picker, which starts on whatever your browser reports and can be changed to any zone your browser knows. That matters because cron itself has no time zone of its own: it matches the local wall clock of the machine the daemon runs on. A container running in UTC and a laptop in Kuala Lumpur will fire the same expression eight hours apart. Some crond builds accept a CRON_TZ= line at the top of a crontab, and systemd timers take an explicit zone; neither is part of the expression, so neither can be read out of one.
What happens when the clocks change?
This page reports the wall-clock time, which is the same thing the expression names. Whether your scheduler skips a job whose hour never happened, runs it late, or runs it twice on the morning the clocks go back is a property of that scheduler, not of the expression — Vixie cron, systemd timers and Kubernetes all answer it differently. When a run falls in a gap or a repeat, the list above marks the row so you know a decision is being made somewhere else. Schedules pinned to a UTC machine avoid the question entirely.
How do I say “the last day of the month” or “the third Friday”?
You cannot, in standard cron. “L”, “W” and “5#3” are Quartz extensions, and this page names them rather than pretending to evaluate them. For the last day of the month the usual workaround is a daily job whose script exits unless tomorrow is the 1st. For the third Friday, the window is the 15th to the 21st — that seven-day span contains exactly one Friday — so you write “0 0 15-21 * *” and let the script exit unless the day is a Friday. Note the “*” in the day-of-week field: writing “0 0 15-21 * 5” instead looks like the obvious answer and is wrong, because both day fields are then restricted and the either-matches rule fires it on all seven dates and on every other Friday of the month as well. Paste both above and compare the run lists.
Does anything I type here leave the browser?
No. The parser, the calendar arithmetic and the run-time search are all JavaScript this page already loaded, the time zone list comes from your browser’s own internationalisation data, and nothing is written to localStorage — so closing the tab leaves nothing behind. That matters more than it sounds for this tool: a cron line is usually copied straight out of production infrastructure, and the comment beside it often names the host.