Skip to main content
Redmoon Converters
⚙️ Developer Tools

Cron Expression Builder & Translator

Build cron expressions from dropdowns or paste any cron string to see plain-English meaning and the next 5 fire times. Standard five-field Unix crontab syntax.

Built and maintained by Paul Clark, Redmoon Software · Checked against what this tool computes on

Format: minute hour day-of-month month day-of-week. Lists, ranges and steps supported.
Plain English
Expression:

Next 5 fire times

#Date / timeIn
Quick reference

Each field is parsed into the set of allowed values. * = all, 1-5 = range, */5 = step, 1,15,30 = list. Next-fire times are found by walking forward minute-by-minute and checking field membership, with day-of-month / day-of-week OR semantics when both are restricted (Unix standard).

How it works

Each of the five fields is expanded into the set of values it allows: an asterisk becomes the entire range, 1-5 a range, */15 a step, and 1,15,30 a list. Next fire times are then found by brute force, walking forward one minute at a time from now, converting each candidate into your selected timezone and testing set membership, up to one year ahead. A 7 in the day-of-week field is normalised to 0 for Sunday.

Mode switches between Parse / translate, where you paste an expression (the default is */15 9-17 * * 1-5), and Visual builder, which offers five separate boxes joined back into a single string. The Timezone dropdown matters more than it appears: it changes only the next-fire list, so the same expression produces different clock times for a UTC server and your local zone. Seven presets cover Every minute through Sunday midnight.

This parser handles 5-field Unix crontab and nothing else. Six- and seven-field Quartz or AWS EventBridge expressions are rejected outright, as are the extensions many schedulers add: L, W, #, question-mark day fields, @daily-style shorthands, and three-letter names such as MON or JAN. Field values are not bounds-checked either, so 99 * * * * parses happily and simply never fires. The plain-English description is always rendered in English regardless of page language.

Frequently asked questions

What does */15 9-17 * * 1-5 actually mean?

That is the default expression: every 15 minutes, during hours 9 through 17, Monday to Friday. It fires at :00, :15, :30 and :45 of each of those hours, which the next-fire table confirms in whichever timezone you have selected.

If I set both day-of-month and day-of-week, must both match?

No. When both fields are restricted, cron fires when either matches, and this tool implements that Unix standard. If only one of the two is restricted, that field alone decides. Leaving both as asterisks means every day.

Is Sunday 0 or 7 in a cron expression?

Both work here. Any 7 in the day-of-week field is rewritten to 0 before parsing, so 0 0 * * 0 and 0 0 * * 7 describe the same Sunday-midnight schedule. The visual builder labels that field Day of week (0=Sun).

Which timezone are the next fire times shown in?

Whichever you choose in the Timezone dropdown, which starts on your browser's own zone and is populated from your browser's timezone database. Bear in mind that cron on a server normally follows that machine's clock, not yours, so pick accordingly.

Why does my cron expression come back as invalid?

The parser demands exactly five whitespace-separated fields containing numbers, ranges, steps or lists. Six-field Quartz strings, @hourly shorthands and name forms such as JAN or MON all fail, and the error message tells you how many fields it actually counted.

Five fields, and the one rule that catches everyone

A standard cron expression is minute, hour, day-of-month, month, day-of-week. The rule that produces most unexpected behaviour is that when BOTH day-of-month and day-of-week are restricted, they are combined with OR rather than AND.

So `0 0 1 * 1` does not mean "the first of the month, if it is a Monday". It means "the first of the month, and also every Monday" — which fires roughly five times as often as intended. Expressing "the first Monday" requires either a day-of-month range with a weekday restriction, or logic in the job itself.

Time zones, missed runs and overlap

Cron runs in the time zone of the system or of the scheduler's configuration, and daylight-saving transitions are where scheduled jobs fail silently: a job scheduled at 02:30 does not run on the day the clock jumps forward, and runs twice on the day it falls back. Scheduling in UTC avoids both.

Cron also has no concept of a missed run. A machine asleep or down at the scheduled time simply does not run the job, and nothing catches up afterwards — which is why anything that must happen needs a job that checks whether work is outstanding rather than assuming its own schedule fired.

Nor does cron prevent overlap: a job that takes longer than its interval will have a second copy started on top of it. Locking is the caller's responsibility.

Where these numbers come from

The standard or formula behind this tool, so you can check it rather than take it on trust.

  • POSIX crontab specification

    The five-field format. Note the rule that catches everyone: when both day-of-month and day-of-week are restricted, they are ORed, not ANDed — so a schedule meant for "the first Monday" fires far more often than intended.

Related tools