Skip to content

Cron expression parser

  • Runs on your device
  • Works offline once loaded

Type a cron schedule and read what it means, then check the next runs in the time zone you care about. Edit each field separately, try presets such as every 15 minutes or weekdays at 8:30, and use the seconds field if your scheduler has one.

How it works

  1. Enter a cron expression or pick a preset.
  2. Read the plain English description.
  3. Check the upcoming run times in your time zone.

Why use it

  • Plain English explanation.
  • Next 5 to 50 runs.
  • Any IANA time zone.
  • Five or six field expressions.

Reading cron expressions, and checking when they run

The five fields

A cron expression is five values separated by spaces, read left to right: minute, hour, day of the month, month and day of the week. A * means every value. Linux crontab, GitHub Actions, Kubernetes CronJobs and most job schedulers use this format.

FieldAllowed valuesExample
Minute0 to 59*/15 every 15 minutes
Hour0 to 239-17 from 9:00 to 17:00
Day of month1 to 311 on the first
Month1 to 12 or JAN to DEC*/3 every third month
Day of week0 to 7 or SUN to SAT, 0 and 7 both Sunday1-5 Monday to Friday

Commas list values (1,15), dashes give ranges (9-17), and a slash gives steps (*/10). The default example, */15 9-17 * * 1-5, runs every 15 minutes from 9:00 to 17:45 on weekdays. Some systems, such as Quartz and some cloud schedulers, add a sixth field for seconds at the front: */5 * * * * * runs every 5 seconds. The parser accepts both.

The traps

  • Day of month and day of week together. 0 9 1 * 1 runs at 9:00 on the first of the month and on every Monday, not only on Mondays that fall on the first. The next runs list shows it at once.
  • `9-17` includes 17. With */15 in the minute field, the last run is 17:45, not 17:00.
  • Time zones. Servers often run cron in UTC. A job set for 9:00 runs at 9:00 UTC, which is 10:00 or 11:00 in Paris depending on the season. Pick the server's time zone in the list to see the real times.
  • Daylight saving time. On the night clocks change, a job at 2:30 can run twice or not at all, depending on the scheduler. Avoid scheduling in the hour around 2:00 local time.

Checking an expression

Type or paste an expression and three things update: a sentence that describes it, a breakdown of each field, and a list of the next runs as dates. Seeing the actual dates is the surest check: if the list shows a run you did not expect, the expression does not mean what you thought. Change the number of runs to 50 to check a whole month of a frequent job, and switch the time zone to compare how it runs on a server elsewhere. A 24 hour clock and a more verbose wording are available.

Related tools

Cron logs and job systems usually record times as Unix timestamps; the timestamp converter turns them into dates in any time zone. Unix timestamps explained covers the format and its pitfalls.

If something goes wrong

  • It says the expression is invalid. Count the fields: five, or six with seconds. A value is out of range, such as 24 for the hour or 60 for the minute.
  • The next runs are not what you expected. Check the time zone, then the day of month and day of week fields.
  • Your scheduler rejects an expression that works here. Schedulers differ: some do not accept names like MON, a seconds field, or special characters such as L and #.

Questions and answers

What does */15 mean?

It means every 15 units of that field, so */15 in the minutes field runs at minute 0, 15, 30 and 45.

Does it support seconds?

Yes. A six field expression uses the first field for seconds.

Are the run times exact?

They are calculated from the expression and the chosen time zone, including daylight saving changes.

Related guides

Data5 min read

Unix timestamps explained

A Unix timestamp is just a count of seconds, yet it causes a steady stream of bugs. What it counts, how to tell seconds from milliseconds at a glance, what happens with time zones and leap seconds, and why 2038 matters.

Esc