Cron Expression Parser

What one result line contains

The expression must be five whitespace-separated fields: minute, hour, day of month, month, weekday. Stars, lists, ranges, and steps are accepted, and so are English month and weekday names in any letter case. 0 9 * jan mon is a valid Monday-in-January schedule. A sixth field, including a leading seconds field, stops with Expected 5 fields (minute hour day month weekday). Seconds, Quartz and year fields are unsupported. A question mark, as in a Quartz day field, stops earlier: Supports numeric fields, month/weekday names, lists, ranges and steps; Quartz modifiers are unsupported. A minute of 99 stops with Constraint error, got value 99 expected range 0-59. A step of */0 stops with Constraint error, cannot repeat at every 0 time.

Each success line is the UTC ISO time from toISOString, then an em dash, then Intl.DateTimeFormat with en-GB, dateStyle full, and timeStyle long, in the timezone you typed. For the sample, the first line is 2026-10-12T09:00:00.000Z — Monday, 12 October 2026 at 09:00:00 UTC. The same expression in Europe/Stockholm, with the same start, begins 2026-10-12T07:00:00.000Z — Monday, 12 October 2026 at 09:00:00 CEST. The local clock stays 09:00. The UTC instant moves with the offset. The page always prints five lines, or an error and no lines. It does not print a sixth run and it does not describe the expression in a sentence of its own.

Load sample, Timezone, and a blank start

Load sample writes three values and nothing else: the expression 0 9 * * 1-5, the start 2026-10-10T00:00:00Z, and the timezone UTC. Next five runs stays empty until you press Show next run times. Reset clears the expression, the start, the five lines, and the error message. It does not put UTC back if you had typed America/New_York, and it does not restore the sample. A blank start is replaced, at click time, with the browser clock as an ISO string that already ends in Z. A start that does not parse says Enter a valid ISO start time with timezone. A start that parses but has no Z and no +hh:mm or -hh:mm suffix says Start time must include Z or an explicit UTC offset. 2026-10-10T00:00:00 is rejected. 2026-10-10T00:00:00Z is accepted.

Timezone is passed to Intl and to the scheduler. Invalid/Zone fails with Invalid time zone specified: Invalid/Zone. Abbreviations such as EST are not IANA names and are not a substitute. The field starts as UTC on a fresh visit. The calculation uses the zone for the schedule, then prints both the UTC instant and the wall time in that zone, so a later reader can see the offset without opening the page in the same place. A single numeric epoch, with no schedule, belongs on the timestamp converter. This page will not turn 1700000000 into a calendar line, and that converter will not expand a cron expression.

When a schedule is the thing you are checking

Use the five lines when you are about to commit a crontab, a platform scheduler that accepts five Unix fields, or a ticket that says weekdays at 09:00. The sample is that check: from Saturday 10 October 2026 the first hit is Monday, and Friday 16 October is the fifth. A deploy window that must avoid Saturday is visible because Saturday never appears. The page does not install the job, call a host, or keep a timer. Copy the lines into the ticket if the reviewer needs the instants. The download is the same five lines in cron-parser.txt.

An identifier that happens to contain a time is a different object. UUID version 7, ULID, and a MongoDB ObjectID pack a timestamp into an id. The guide UUID v4 vs UUID v7 vs ULID compares those spellings. Previewing 0 9 * * 1-5 does not decode an id, and decoding an id does not tell you when a cron job will next fire. If a fixture both names a row and expects a scheduled run, do the two checks separately. The UUID v7 generator and the ULID generator are the id tools. This page only walks a five-field schedule.

Day-of-month with weekday, daylight saving, and a start that is already a hit

When both the day-of-month field and the weekday field are restricted, Unix cron matches either field. 0 0 1 * MON from 2026-09-01T00:00:00Z in UTC prints Monday 7 September, the next Mondays, and then Thursday, 1 October 2026 at 00:00:00 UTC. 1 October 2026 is not a Monday. It appears because the day-of-month field is 1. A reader who expected only Mondays that fall on the 1st will see extra lines. The page follows that either-field rule. It does not offer an AND switch. A day that cannot exist, such as 0 0 30 2 *, stops with Invalid explicit day of month definition. Names and numbers can mix: 0 9 * JUL MON is Mondays in July, and from 2026-07-01T00:00:00Z the first line is Monday, 6 July 2026 at 09:00:00 UTC.

The next run is strictly after the start. 0 9 * * 1 with start 2026-10-12T09:00:00Z, which is already a Monday at 09:00 UTC, prints Monday 19 October first, not 12 October. If you wanted that instant included, start one second earlier. Daylight-saving transitions are whatever the timezone database does for that zone. 30 2 * * * in America/New_York from 2026-03-07T00:00:00Z prints Saturday 7 March at 02:30:00 GMT-5, then Sunday, 8 March 2026 at 03:30:00 GMT-4, because 02:30 does not exist on the spring-forward morning. The fall-back expression 30 1 * * * from 2026-10-31 prints one 01:30 on Sunday 1 November, labeled GMT-4, and the next line is Monday 2 November at 01:30 GMT-5. It does not print a second 01:30 for the repeated hour. Compare these lines with the scheduler you will actually run before you treat them as the deploy plan.

Rules and limitations

Five fields only. Names, lists, ranges, and steps are accepted. Quartz ? , a seconds field, and a year field are rejected. Both a restricted day-of-month and a restricted weekday match if either field matches. The start instant itself is not a result.

Timezone must be an IANA name. Start must end in Z or a numeric offset, or be left blank for the current instant. The result is five lines, UTC ISO, an em dash, and an en-GB full date with a long time. Reset does not restore the timezone. The page does not register a job.

Common problems

If the first line is a week later than the morning you typed, the start is equal to that morning. The preview begins after the start. Move the start earlier and press Show next run times again.

If Sunday 8 March shows 03:30 instead of 02:30, the zone skipped that hour. If 1 November shows only one 01:30, the repeated hour was not listed. Invalid/Zone and a bare EST are not usable timezone values.

Frequently asked questions

About this tool

Maintained by Toolbench. For large or deeply nested files, split the input into smaller batches and verify representative results before using them in an import or application. Report reproducible problems through Contact.