What do the five fields in a cron expression mean?

In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). An asterisk means “every value”. So 0 9 * * 1-5 reads “At 09:00 AM, Monday through Friday” — minute 0, hour 9, any date, any month, weekdays only.

Which syntax extensions are supported?

Beyond plain numbers and asterisks: step values (*/5 in the minute field means every 5 minutes), ranges (1-5), lists (9,17), month and weekday names (JAN, MON-FRI), and L for the last day of the month. Six-field expressions with a leading seconds field also parse — */30 * * * * * reads “Every 30 seconds”. All of these can be combined across fields.

What happens when both day-of-month and day-of-week are set?

The description lists both — 0 0 1 * 1 reads “At 12:00 AM, on day 1 of the month, and on Monday”. In classic Vixie/POSIX cron the two fields are ORed when both are restricted: that job fires on the 1st of every month and on every Monday (five or six days in a typical month), not only when the 1st falls on a Monday. Some schedulers, notably Quartz, treat this pattern differently, so check your runner’s documentation.

Which time zone does a cron schedule run in?

The expression itself carries no time zone — the daemon’s clock decides. Traditional crontabs use the server’s local time, GitHub Actions evaluates schedules in UTC, and some platforms (such as Kubernetes CronJobs) let you set a zone explicitly. The description shown here is zone-neutral: “At 09:00 AM” means 9 AM on whatever clock your scheduler uses.

How does daylight saving time affect cron jobs?

When local clocks spring forward, times inside the skipped hour don’t occur that day; when they fall back, an hour repeats — and cron implementations differ in whether such jobs are skipped, run once, or run twice. If your server sits in a DST-observing zone, avoid scheduling critical jobs between 1:00 and 3:00 AM local time, or run the scheduler in UTC.

Does the tool show the next run times?

No — it produces a human-readable description of the schedule, not a simulation of your scheduler. Exact next-run instants depend on the runner’s clock and time zone. Use this page to verify the expression’s meaning, then confirm timing with your scheduler’s own logs or dry-run tooling.

Is my cron expression uploaded anywhere?

No — parsing happens entirely in your browser. Nothing is uploaded, logged, or stored.

Cron Expression Parser

Explain a cron expression in plain English and preview its schedule.

Runs in your browser — files never leave your device

Cron expression

At 09:00 AM, Monday through Friday

Examples:

How it works

Type a cron expression and the tool translates it into plain English as you type. A standard expression has five fields in fixed order — minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, with 0 meaning Sunday). For example, 30 2 * * 0 describes as “At 02:30 AM, only on Sunday”: minute 30, hour 2, any day of month, any month, Sundays only.

The parser understands the full everyday syntax: * wildcards, lists, ranges, step values, and month or weekday names. 0 9 * * 1-5 reads “At 09:00 AM, Monday through Friday”; */5 * * * * is “Every 5 minutes”; 0 9,17 * * MON-FRI becomes “At 09:00 AM and 05:00 PM, Monday through Friday”; and 0 12 * JAN,JUL * is “At 12:00 PM, only in January and July”. It also accepts the L extension — 0 0 L * * is “At 12:00 AM, on the last day of the month” — and six-field expressions with a leading seconds field, so */30 * * * * * parses as “Every 30 seconds”.

Invalid input produces a specific error instead of a wrong guess: an expression with fewer than five fields is rejected outright, and out-of-range values are flagged per field — 61 in the minute position, for instance. That makes the tool a quick pre-flight check before a schedule lands in a crontab, a GitHub Actions workflow (which uses this same five-field format, evaluated in UTC), a Kubernetes CronJob, or a backup script.

Note what it deliberately doesn’t do: it describes the schedule, it doesn’t simulate your server — actual fire times depend on your scheduler’s clock and time zone. Use the description to confirm the expression says what you meant, then rely on your scheduler’s own logs or dry-run for exact next-run instants.

Frequently asked questions

What do the five fields in a cron expression mean?: In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). An asterisk means “every value”. So 0 9 * * 1-5 reads “At 09:00 AM, Monday through Friday” — minute 0, hour 9, any date, any month, weekdays only.
Which syntax extensions are supported?: Beyond plain numbers and asterisks: step values (*/5 in the minute field means every 5 minutes), ranges (1-5), lists (9,17), month and weekday names (JAN, MON-FRI), and L for the last day of the month. Six-field expressions with a leading seconds field also parse — */30 * * * * * reads “Every 30 seconds”. All of these can be combined across fields.
What happens when both day-of-month and day-of-week are set?: The description lists both — 0 0 1 * 1 reads “At 12:00 AM, on day 1 of the month, and on Monday”. In classic Vixie/POSIX cron the two fields are ORed when both are restricted: that job fires on the 1st of every month and on every Monday (five or six days in a typical month), not only when the 1st falls on a Monday. Some schedulers, notably Quartz, treat this pattern differently, so check your runner’s documentation.
Which time zone does a cron schedule run in?: The expression itself carries no time zone — the daemon’s clock decides. Traditional crontabs use the server’s local time, GitHub Actions evaluates schedules in UTC, and some platforms (such as Kubernetes CronJobs) let you set a zone explicitly. The description shown here is zone-neutral: “At 09:00 AM” means 9 AM on whatever clock your scheduler uses.
How does daylight saving time affect cron jobs?: When local clocks spring forward, times inside the skipped hour don’t occur that day; when they fall back, an hour repeats — and cron implementations differ in whether such jobs are skipped, run once, or run twice. If your server sits in a DST-observing zone, avoid scheduling critical jobs between 1:00 and 3:00 AM local time, or run the scheduler in UTC.
Does the tool show the next run times?: No — it produces a human-readable description of the schedule, not a simulation of your scheduler. Exact next-run instants depend on the runner’s clock and time zone. Use this page to verify the expression’s meaning, then confirm timing with your scheduler’s own logs or dry-run tooling.
Is my cron expression uploaded anywhere?: No — parsing happens entirely in your browser. Nothing is uploaded, logged, or stored.

Cron Expression Parser

How it works

Frequently asked questions

Related tools