Cron Expression Parser

Paste a crontab schedule and get a sentence describing it, a breakdown of all five fields, and the next five run times in your local timezone. Presets included for the schedules you actually need.

Plain-English description

Next 5 run times, local timezone

Field-by-field breakdown

Ranges, steps, lists and name aliases

Detects 6-field Quartz expressions

How to read a cron expression

Paste the expression

Enter the five-field schedule, for example 30 3 * * 1-5. You can also paste shortcuts like @daily or @weekly.

Read the description

The tool turns the expression into a sentence so you can confirm it matches what you intended.

Check the next run times

The next five executions are computed in your browser timezone. This is where off-by-one mistakes become obvious.

Adjust and compare

Tweak a field or start from a preset and watch the run times change until the schedule is right.

The five fields, in order

A crontab line is five space-separated fields: minute hour day-of-month month day-of-week. Minutes run 0–59, hours 0–23, day of month 1–31, month 1–12, and day of week 0–6 where 0 is Sunday. Most implementations also accept 7 for Sunday, and three-letter names like MON or JAN.

Each field accepts four things: a single value (5), a list (1,15,30), a range (1-5) and a step (*/15, or 0-30/5 for every five minutes in the first half hour). An asterisk means "every value".

The day-of-month and day-of-week trap

This is the single most misunderstood part of cron. When both the day-of-month and the day-of-week fields are restricted, cron combines them with OR, not AND. So 0 0 13 * 5 does not mean "Friday the 13th" — it means "midnight on the 13th of every month, and also every Friday".

Getting a true "Friday the 13th" schedule requires a day-of-month check inside the job itself. When exactly one of the two fields is restricted, the behaviour is the intuitive one, which is why the bug hides for so long.

Timezones, and why the run times here may not match your server

The next run times shown on this page are computed in your browser's timezone. Your server almost certainly runs cron in UTC, or in whatever the system timezone happens to be. A daily job at 0 2 * * * fires at 02:00 server time, which may be a completely different hour where you are.

Daylight saving time makes it worse. When the clock jumps forward, jobs scheduled inside the skipped hour may not run at all that day; when it falls back, they can run twice. If a job must not be skipped or duplicated, schedule it in UTC or make it idempotent.

Standard cron, Quartz and the seconds field

Classic Unix crontab has five fields and a one-minute resolution — you cannot schedule anything more frequent than once per minute. Quartz, Spring's @Scheduled, and several job libraries add a seconds field at the front, making six.

If you paste a six-field expression here, the tool tells you rather than guessing, because the same string means different schedules in the two dialects. Some Quartz expressions also use ?, L and #, which standard crontab does not understand.

Frequently asked questions

What does */15 mean in a cron expression?

It is a step value: every 15 units within the field, starting from the lowest allowed value. In the minute field, */15 means minutes 0, 15, 30 and 45 of every hour. Note that it steps from the start of the field, not from the current time.

Are the run times shown in UTC or my local time?

Your local time, taken from your browser. Servers usually run cron in UTC or the system timezone, so compare carefully before assuming a job will fire when this page says it will.

Why does my expression run more often than I expected?

The most common cause is setting both the day-of-month and the day-of-week fields. Cron treats them as OR when both are restricted, so the job runs on either condition. Leave one of them as an asterisk unless you genuinely want both.

Can cron run a job every 30 seconds?

Not with standard crontab, which has a resolution of one minute. The usual workarounds are two entries with a sleep offset, a systemd timer, or a scheduler like Quartz that supports a seconds field.

What is the difference between @daily and 0 0 * * *?

Nothing — @daily is a shorthand that expands to exactly 0 0 * * *. The other shortcuts are @hourly, @weekly, @monthly and @yearly. @reboot is different: it runs once at startup and has no recurring schedule.

Does day of week start at 0 or 1?

0 is Sunday in standard cron, running through 6 for Saturday. Most implementations also accept 7 as Sunday. Three-letter names like SUN, MON and FRI work too and are far easier to read.

Related tools

Developers