Every fifteen minutes
Input
*/15 * * * *
Result
Every 15 minutes every day
Runs at :00, :15, :30 and :45 of every hour. Replace 15 with 5 for a five-minute interval.
Five fields: minute, hour, day-of-month, month, day-of-week. Six fields are also accepted, where the first field is seconds. Runs entirely in your browser.
At 09:00 on weekdays
- Standard 5-field format: minute hour day-of-month month day-of-week.
Next 10 executions
UTC+00:00| # | Local time (UTC) | UTC |
|---|---|---|
| 1 | Wed, 30 Sept 2026, 09:00:00 | 2026-09-30T09:00:00Z |
| 2 | Thu, 01 Oct 2026, 09:00:00 | 2026-10-01T09:00:00Z |
| 3 | Fri, 02 Oct 2026, 09:00:00 | 2026-10-02T09:00:00Z |
| 4 | Mon, 05 Oct 2026, 09:00:00 | 2026-10-05T09:00:00Z |
| 5 | Tue, 06 Oct 2026, 09:00:00 | 2026-10-06T09:00:00Z |
| 6 | Wed, 07 Oct 2026, 09:00:00 | 2026-10-07T09:00:00Z |
| 7 | Thu, 08 Oct 2026, 09:00:00 | 2026-10-08T09:00:00Z |
| 8 | Fri, 09 Oct 2026, 09:00:00 | 2026-10-09T09:00:00Z |
| 9 | Mon, 12 Oct 2026, 09:00:00 | 2026-10-12T09:00:00Z |
| 10 | Tue, 13 Oct 2026, 09:00:00 | 2026-10-13T09:00:00Z |
Describe it in words
Deterministic pattern matching — no AI, no guessing. Recognised patterns are listed on this page.
What a cron expression actually says
A cron expression is a compact description of a repeating schedule. The classic crontab form has five fields separated by spaces, and they always appear in the same order: minute, hour, day of month, month and day of week. Each field accepts a value, a list, a range or a step, and an asterisk for “no restriction here”. Reading a schedule is mostly a matter of translating those five positions into a sentence, which is exactly what the parser above does.
The compactness is what makes cron useful and also what makes it error-prone. 0 0 1 * * and 0 0 * * 1 differ by a single character and mean completely different things — the first runs monthly, the second runs weekly. A misread schedule typically shows up as a job that quietly never runs, or one that runs far more often than anyone intended, and both are expensive to notice after the fact.
The field ranges are worth memorising because they explain most validation errors: minutes and hours start at zero, but days of the month and months start at one, while days of the week start at zero for Sunday. This tool refuses out-of-range values and names the field that is wrong, instead of silently accepting an expression that no scheduler would run.
Daylight saving is where schedules break
Almost every scheduling bug that survives a code review is a time zone bug. Cron expressions describe wall-clock time, not fixed instants, so 0 9 * * * means “nine in the morning as the local clock reads it” — and the UTC instant behind that reading moves by an hour twice a year in most of Europe and North America.
The two transitions behave in opposite ways and both are easy to miss. On a spring-forward day the clock jumps from 02:00 to 03:00, so any job scheduled inside that missing hour — say 30 2 * * * — simply does not run that day. On a fall-back day the clock repeats an hour, so a job scheduled inside it runs twice, which means duplicated invoices, duplicated emails and duplicated database writes if the job is not idempotent.
This parser calculates the next runs from the browser's own time zone database and shows the local time, the UTC instant and the active UTC offset side by side. That makes the transition visible: the same 09:00 job appears as 13:00 UTC during daylight saving and 14:00 UTC outside it. If you need a job to run at a fixed instant regardless of the season, schedule it in UTC explicitly.
Supported syntax, and what is deliberately left out
Cron has no single specification. The original Vixie cron defined the five-field layout that Unix-like systems still use, and other platforms extended it in incompatible ways. Rather than pretending that every dialect is supported, here is the exact boundary of this tool.
Supported syntax
| Syntax | Example | Support |
|---|---|---|
* , - / | 0 */6 * * 1-5 | Fully supported |
? | 0 12 ? * MON | Supported (treated as *) |
| Names for months and weekdays | 0 0 1 JAN * | Supported |
| Wrapping ranges | 0 22-2 * * * | Supported (runs 22:00 to 02:00) |
| Seconds field (6 fields) | */30 * * * * * | Supported and detected automatically |
L (last day) | 0 0 L * * | Not evaluated — reported explicitly |
W (nearest weekday) | 0 0 15W * * | Not evaluated — reported explicitly |
# (nth weekday) | 0 0 * * 1#2 | Not evaluated — reported explicitly |
| Year field (7 fields, Quartz) | 0 0 0 1 1 * 2027 | Rejected with an explanation |
Platform differences worth knowing
If an expression works in one system and not another, the layout is usually the reason. Standard crontab entries have five fields and require a script path after them. AWS EventBridge Scheduler and Quartz use six fields with seconds first, and Quartz additionally supports theL, W and # extensions plus a year field. Systemd does not use cron syntax at all: its OnCalendar format is different in every position, so translating between the two requires care rather than a find-and-replace.
The practical advice is to decide which scheduler owns the job and then keep the expression in that dialect. Copying a six-field AWS schedule into a five-field crontab shifts every field by one position, which turns “every day at midnight” into “every minute during the midnight hour” — a mistake that is invisible until it floods your logs.
Common schedules explained
Weekdays at 09:00
Input
0 9 * * 1-5
Result
At 09:00 on weekdays
Skips Saturday and Sunday. Beware public holidays: cron has no concept of them.
Every six hours
Input
0 */6 * * *
Result
At 00:00, 06:00, 12:00 and 18:00 every day
The step applies within the field, so the run times stay aligned to midnight.
Midnight on the 1st of each month
Input
0 0 1 * *
Result
At 00:00 on day 1 of the month
Runs once a month. On a fall-back day, double-check any job scheduled inside the repeated hour.
Every thirty seconds (six fields)
Input
*/30 * * * * *
Result
Every 30 seconds
Six-field layout with seconds first. Standard crontab would read this as a five-field expression and misbehave.
Frequently asked questions
How do I read a cron expression?
Read the five fields from left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12) and day of week (0-6, where 0 is Sunday). The expression 0 9 * * 1-5 therefore means "at minute 0 of hour 9, on any day of the month, in any month, when the weekday is Monday to Friday" — that is, 09:00 on weekdays. An asterisk means "every possible value", a comma lists values, a hyphen defines a range and a slash defines a step, so */15 in the minute field means every fifteen minutes.
Why does my job run at the wrong hour after a daylight-saving change?
Most cron daemons schedule on wall-clock time in the server time zone, so the UTC instant of a 09:00 job shifts by an hour when the clocks change. If your job must run at a fixed UTC instant, schedule it in UTC and convert your intent once. Two details cause most confusion: on a spring-forward day a job scheduled inside the skipped hour (for example 02:30) never runs, and on a fall-back day a job scheduled inside the repeated hour runs twice. This tool shows both cases explicitly so you can plan around them.
What is the difference between five-field and six-field cron?
A standard crontab entry has five fields and no seconds, so the smallest interval is one minute. Systems such as AWS EventBridge Scheduler and Quartz use a six-field layout where the first field is seconds, which allows intervals like */30 * * * * * (every thirty seconds). Some tools also accept a seventh year field. This parser detects six fields automatically and says so, because silently treating a seconds field as minutes is a very common source of double or missing runs.
How are day-of-month and day-of-week combined?
This is the rule that surprises people most. When both the day-of-month and day-of-week fields are restricted to specific values, the entry matches when either one matches — a logical OR. So 0 0 13 * 5 runs at midnight on the 13th of the month and also on every Friday. When only one of the two is restricted, only that field has to match. Modern systems add their own extensions, but the OR behaviour comes from the original Vixie cron and is what most crontab implementations still do.
Which cron syntaxes are not supported here?
Quartz-specific extensions are deliberately not evaluated: L for the last day of the month, W for the nearest weekday and # for the nth weekday. Rather than guessing at them, this tool reports the unsupported token and points you to the alternatives shown in the supported-syntax table. Expressions with a trailing year field are also rejected, because Quartz adds that field in a position that would otherwise be read as part of the day-of-week field.
Does the time zone selector change the schedule itself?
No — the expression stays exactly as you wrote it and is always interpreted as a wall-clock schedule. Changing the time zone changes the reference clock used to turn that schedule into concrete instants, which is what makes the "next runs" list and the UTC column shift. This matters for servers in one region and users in another: a job defined as 09:00 Asia/Tokyo fires at a completely different moment than 09:00 Europe/London.
Can I turn a sentence into a cron expression?
Yes, for a small and deliberately limited set of phrasings such as "every 15 minutes", "weekdays at 9am", "every monday at 9 am" and "on the 1st of month at 0:00". The converter uses deterministic pattern matching rather than a language model, so it either produces a correct expression or tells you it did not recognise the sentence — it never invents a plausible-looking schedule that quietly means something else. If your sentence is not matched, write the expression directly and use the description to confirm it.
Is the cron calculator safe to use with production schedules?
Everything runs locally in your browser: the expression, the selected time zone and the calculated run times never leave your machine, and the tool makes no network requests at all. That matters when a schedule reveals the existence of internal jobs or maintenance windows. You can confirm it in your browser DevTools by opening the Network tab and typing an expression — no request is made.
What this tool does not do
- It does not run jobs. It only explains expressions and previews when they would fire.
- It does not evaluate Quartz-only syntax (L, W, #) or expressions with a trailing year field. Unsupported input is reported instead of approximated.
- It does not know about your scheduler’s catch-up behaviour after downtime, jitter, or overlap protection — those are runtime policies, not part of the expression.
- It does not fetch the server’s time zone. Select the time zone the scheduler actually runs in, otherwise the previewed runs will be offset.
- It does not keep a history of the expressions you type.