Skip to content

Cron Expression Explainer

Turn a cron expression into a plain sentence and list up to 20 upcoming run times in the time zone you pick. Reads 5 fields, or 6 with seconds first.

5 fields

Description

At 09:00 AM, Monday through Friday

Next run times

Browser time zone: UTC

Enter a valid expression to see its next run times.

Field reference & cheat sheet

Field reference & cheat sheet
FieldMeaningValues
secondSecond (only with 6 fields)0-59
minuteMinute0-59
hourHour0-23
day of monthDay of month1-31
monthMonth1-12 or JAN-DEC
day of weekDay of week0-7 (both 0 and 7 mean Sunday) or SUN-SAT

Quartz-only tokens (L, W, #, ?) aren't supported here. Only the standard 5- or 6-field syntax is read.

Common macros

Examples

What you enter is processed only in this browser and is never sent to a server. How it works

0 9 * * * interpreted as 09:00 daily in the selected time zone

Enter */15 9-17 * * 1-5 and you get the sentence “Every 15 minutes, between 09:00 AM and 05:59 PM, Monday through Friday”, followed by the actual dates and times the job would run. Use it to confirm an expression reads the way you meant before you put it on a server.

How to use it

  1. Type an expression into the Cron expression box. It starts out as 0 9 * * 1-5. The note under the box tells you whether it was read as “5 fields” or “6 fields (seconds first)”.
  2. Description shows the expression written out as a sentence. “Copy expression” copies the tidied-up expression. If you entered a macro, it copies the expanded fields instead (for example, @daily → 0 0 * * *).
  3. Under Next run times, set “Count” (1–20) and “Time zone”. Run times from now onward are listed as dates and times in that zone.
  4. Under Field reference & cheat sheet, clicking a button in “Common macros” or “Examples” puts that expression into the input box.

When the syntax is wrong, the error names the field and the value that caused it. Enter 60 * * * * and you see this message: “60” in the minute field is outside the allowed range.

Field syntax

Fields are separated by spaces, and there must be 5 or 6 of them. Five are read as minute, hour, day of month, month, day of week. With six, the first one is read as seconds.

Field Values
Second (only with 6 fields) 0-59
Minute 0-59
Hour 0-23
Day of month 1-31
Month 1-12 or JAN-DEC
Day of week 0-7 (both 0 and 7 mean Sunday) or SUN-SAT

Each field accepts these forms.

  • *: every value
  • 5: that one value
  • 1-5: a range. A start that is larger than the end (5-1) is an error
  • */15: an interval. In the minute field, minutes 0, 15, 30 and 45
  • 5/15: an interval with a starting value. In the minute field, every 15 minutes from minute 5 (5, 20, 35, 50)
  • 10-40/10: an interval inside a range. In the minute field, minutes 10, 20, 30 and 40
  • 1,15: a comma-separated list. You can mix any of the forms above in one list

Seven macros are understood. @yearly and @annually stand for 0 0 1 1 *, @monthly for 0 0 1 * *, @weekly for 0 0 * * 0, @daily and @midnight for 0 0 * * *, and @hourly for 0 * * * *. @reboot means “run once when the system starts”, which leaves no time to calculate, so it is not read.

When you set both day of month and day of week

Put something other than * in both fields and the job runs on days that match either one, not only on days that match both. This is the Unix cron rule described in the crontab manual, and it is how this tool calculates the next run times.

0 0 13 * 5 does not mean Friday the 13th. Calculated on October 10, 2026 with the time zone set to UTC, the list goes Tuesday, October 13, then Friday, October 16, then Friday, October 23. The job runs on the 13th whatever the weekday, and on every Friday whatever the date.

The description for this expression reads “At 12:00 AM, on day 13 of the month, and on Friday”, which can sound as though both conditions have to be met. So for an expression like this, a note under the description says the job runs on days that match either one. Check the actual dates in the list of next run times.

Time zones with daylight saving time (DST)

Choose a time zone that observes daylight saving time and the run times on the days the clocks change look different from usual. These results were calculated for America/New_York with 2026 dates.

  1. A time that doesn’t exist on the day DST starts: on March 8 the clock jumps from 2 AM to 3 AM, so there is no 2 o’clock hour. 30 2 * * * (every day at 2:30 AM) shows 3:30:00 AM on that day only, and goes back to 2:30:00 AM the next day. The run isn’t skipped. It is shown one hour later.
  2. A time that comes twice on the day DST ends: on November 1 the 1 o’clock hour happens twice. An expression that fixes the hour as a number, such as 30 1 * * *, shows 1:30:00 AM just once that day. An expression where the hour is *, such as 0 * * * *, shows 1:00:00 AM twice.

How a real scheduler handles these times depends on the program. If you have a job that runs between 1 AM and 3 AM, check your server’s cron documentation too.

Sources

Frequently asked questions

If I use an interval that doesn't divide 60, like */7, does the job run exactly every 7 minutes?

No. The interval starts counting again from minute 0 of every hour. Look at the next run times for */7 * * * * and you see runs at minutes 0, 7, 14, …, 49 and 56, and then minute 0 of the next hour. Only 4 minutes separate minute 56 from minute 0. Intervals in the hour, day and month fields restart from the beginning of their range in the same way.

I entered 0 0 30 2 * and got "This date isn't on the calendar, so the job would never run". Why?

The syntax is fine, but no such date exists. In 0 0 30 2 * every field is within its range, but there is no February 30, so there is no day for the job to run. The tool reports this as an error and shows no description or next run times. A day that exists only in some months, as in 0 0 31 * *, gives no error. The list simply shows the months that have a 31st.

Can I write the weekday as MONDAY, or in a language other than English?

No. Names are read only as three-letter English abbreviations (SUN-SAT, JAN-DEC), in upper or lower case. Enter MONDAY and you get this error: "MONDAY" in the day of week field isn't a value this tool understands. Names also work in ranges such as MON-FRI and lists such as mon,wed, but month names are accepted only in the month field and weekday names only in the day-of-week field.

My server runs on UTC but my browser is in a different time zone. Which time zone should I choose?

Choose the time zone of the server where cron actually runs. Calculate 0 9 * * 1-5 with "UTC" and the list says 9:00:00 AM. In a time zone nine hours ahead of UTC (UTC+9), that moment is 6 PM. Switch to a UTC+9 time zone and the list still says 9:00:00 AM, but that moment is midnight UTC on the same day. The times in the list are always given in the time zone you selected, and when you first open the page the selected zone is the one shown under "Browser time zone".

Can I paste a Quartz or AWS cron expression unchanged?

They are all called "cron expressions", but the syntax changes from system to system. This tool reads only the 5 fields of Unix cron, and the 6-field form that puts seconds in front of them. • Unix cron (crontab): 5 fields, namely minute, hour, day of month, month and day of week. The day of week runs 0-7, and both 0 and 7 are Sunday. • Quartz (the Java scheduler): seconds come first and a year can be added at the end, which makes 6 to 7 fields. The day of week runs 1-7 with 1 as Sunday, so every number is off by one from Unix cron. It also has symbols Unix cron lacks: L (the last of the month or week), W (the nearest weekday), # (6#3 is the third Friday) and ? (a placeholder for whichever of day of month and day of week you leave unspecified). • AWS EventBridge: 6 fields, namely minute, hour, day of month, month, day of week and year. There are no seconds, and the year sits at the end. The day of week is 1-7 or SUN-SAT, and one of day of month and day of week must be ?. It uses L, W and # as well. • Other cloud schedulers: services with a syntax close to Unix cron, such as Google Cloud Scheduler, can still differ in the details. Paste in an expression written for another system and it will fail or be read differently. The AWS documentation's example 0 10 * * ? * (every day at 10:00) has 6 fields, so this tool reads the first one as seconds, takes the ? in fifth place as a value for the month field, and reports the error: "?" in the month field isn't a value this tool understands. Check Quartz and AWS expressions in that service's own documentation or console.

Open-source software used: cronstrue (MIT), cron-parser (MIT), Luxon (MIT)

Last updated: