Cron Expression Parser

about this tool

Reading an expression before trusting it

Paste a cron expression and get it back in plain English, with the next several run times listed in the timezone you choose. Five fields are standard; six are accepted for the schedulers that add seconds. The named shortcuts — @daily, @midnight, @hourly, @weekly, @monthly and @yearly — are expanded for you. @reboot is recognised and named for what it is: an entry with no schedule, which fires once when the machine starts.

Seeing actual dates is the point. "Every 15 minutes past every hour" sounds right until you read the times and notice it only runs four times a day.

Building one instead

Switch the fields from read to build and every field gets a control of its own: every value, every n, a set of chosen values, or a range with an optional step. Months and days of the week are picked by name rather than by number, which removes the two off-by-one traps in cron — months count from one, days of the week count from zero with Sunday first.

The expression itself stays in charge. The editors read it and rewrite it, so you can paste one in, adjust a single field, and copy it back out; and the description and the run times update as you go. A field the editors cannot model — MON#2, L, 15W, a ? — is held as text and handed back exactly as it came, because those mean different things in different schedulers and rewriting them would change the schedule.

Problems are reported at the field they belong to. A backwards range like 5-1, a value outside its field, a step of zero: each is named where you can fix it, rather than as one error at the end. Some of these are worth knowing about because a scheduler will reject them outright even though the expression still reads as English.

The field that catches everyone

The two day fields — day of month and day of week — are ORed, not ANDed, whenever both are restricted. So:

0 0 13 * 5

does not mean "Friday the 13th". It means the 13th of every month, and every Friday, which is roughly five times as many runs as intended. This is the single most common cron mistake, it is not a bug, and it is specified behaviour that surprises nearly everyone. The tool warns you when an expression has both fields restricted.

The correct way to get Friday the 13th is a day-of-month restriction plus a check inside your job.

Step values

*/15 in the minutes field means every 15 minutes. Two details bite:

• Steps count from the start of the range, not from now. */20 fires at :00, :20 and :40 — not twenty minutes from whenever you deployed.
• A step that does not divide evenly leaves a gap. */45 fires at :00 and :45, then again at :00 — a 15-minute interval across the hour boundary, which is almost never what was meant.

Timezones, and the two days a year that matter

Cron runs in some timezone, and which one depends on the system: many schedulers default to UTC, plenty of servers use local time, and containers frequently disagree with their host. The zone selector here exists so you can check the difference.

Daylight saving is where this becomes real. A job scheduled at 02:30 local time does not run at all on the day the clocks spring forward, because 02:30 does not exist, and may run twice when they fall back. Anything that must not be skipped or duplicated should be scheduled in UTC, or at a time no transition touches.

To see what a specific stored time is in several zones at once, the timestamp converter does that. For the other repeating-schedule syntax — the one calendars use — the RRULE builder & explainer reads and writes those.

Local

Parsing, building and the run-time calculation all happen in the page.

questions

Does 0 0 13 * 5 mean Friday the 13th?

No, and this is the most common cron mistake. When both day-of-month and day-of-week are restricted they are ORed, so it means the 13th of every month AND every Friday. Getting Friday the 13th requires a day-of-month restriction plus a check inside the job.

What does */15 actually do?

It fires every 15 minutes counting from the start of the range, so at :00, :15, :30 and :45 — not fifteen minutes from when you deployed. A step that does not divide evenly leaves a gap: */45 fires at :00 and :45, then :00 again.

What timezone does cron use?

It depends on the system: many schedulers default to UTC, plenty of servers use local time, and containers often disagree with their host. That is why the timezone selector exists here — so you can compare.

What happens to a cron job during daylight saving?

A job scheduled at 02:30 local time does not run at all on the day clocks spring forward, because that time does not exist, and may run twice when they fall back. Schedule anything that must not be skipped or duplicated in UTC.

Does it support seconds and @daily shortcuts?

Yes. Five fields are standard and six are accepted for schedulers that add seconds, and the named shortcuts @daily, @midnight, @hourly, @weekly, @monthly and @yearly are expanded for you. @reboot is recognised but has no schedule to project, since it fires once at startup.

Can it build an expression rather than only read one?

Yes. Switch the fields to build and each one gets a control: every value, every n, chosen values, or a range. Months and days are picked by name. The expression is rewritten as you go and described back to you in words.