Which cron dialect is this?

Standard five-field Unix cron: minute, hour, day of month, month, day of week. Ranges, steps, lists and names like MON or JAN are all supported.

Why do day-of-month and day-of-week both matter?

When both are restricted, classic cron runs the job if either matches — not both. It is a long-standing gotcha, so check the listed run times rather than assuming.

Does this need an internet connection?

Only to load the page. Parsing the expression and calculating run times happen locally, so it keeps working if you go offline afterwards.

Developer tools

Cron Expression Generator

Build a cron schedule and read it back in plain English.

Cron expression

In plain English

At 09:00 AM, Monday through Friday

minute

hour

day

month

1-5

weekday

Next 8 runs

10/9/2026, 9:00:00 AMFri
10/12/2026, 9:00:00 AMMon
10/13/2026, 9:00:00 AMTue
10/14/2026, 9:00:00 AMWed
10/15/2026, 9:00:00 AMThu
10/16/2026, 9:00:00 AMFri
10/19/2026, 9:00:00 AMMon
10/20/2026, 9:00:00 AMTue

About this tool

Type a cron expression and read it back in plain English, with the next several run times listed so you can confirm it fires when you think it does. Common schedules are one click away if you would rather not hand-write the fields.

How to use it

Enter an expression, or pick one of the presets.
Read the plain-English description to confirm the intent.
Check the upcoming run times before shipping it.

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

This catches experienced people, because it is the one place cron uses OR where you would expect AND.

The five fields are minute, hour, day-of-month, month, day-of-week. When both day fields are restricted, classic cron runs the job if either matches — not both.

So this:

0 0 13 * 5

does not mean "midnight on Friday the 13th". It means "midnight on the 13th of every month, and also midnight every Friday". That is roughly nine times more often than intended.

If either day field is *, the behaviour is the intuitive one and there is no problem. The ambiguity only appears when both are constrained — which is why this tool lists the actual next run times. Read those rather than trusting your reading of the expression.

Steps, ranges and the things cron cannot do

Step values repeat at an interval. */15 in the minute field means every fifteen minutes. 0-30/5 means every five minutes during the first half hour only.

A common mistake is thinking */90 gives you every ninety minutes. Each field is independent, so the largest minute step is 59 — there is no way to express an interval longer than the field. Every ninety minutes needs two entries, or a different scheduler.

Ranges and lists combine: 1-5 is Monday to Friday, 1,3,5 is Monday, Wednesday, Friday, and MON-FRI works too.

Cron has no memory. If the machine is asleep or down when a job was due, standard cron does not run it late — the moment simply passed. anacron and systemd timers with Persistent=true do catch up; plain cron does not.

Timezones are the other surprise. Most cron daemons use the system timezone, so a job scheduled for 02:30 may run twice or not at all on daylight-saving changeover nights. Schedule anything critical outside the 01:00–03:00 window, or run the machine on UTC.

Frequently asked questions

Which cron dialect is this?: Standard five-field Unix cron: minute, hour, day of month, month, day of week. Ranges, steps, lists and names like MON or JAN are all supported.
Why do day-of-month and day-of-week both matter?: When both are restricted, classic cron runs the job if either matches — not both. It is a long-standing gotcha, so check the listed run times rather than assuming.
Does this need an internet connection?: Only to load the page. Parsing the expression and calculating run times happen locally, so it keeps working if you go offline afterwards.