Toolrack

Cron Expression Parser

Works offlineNothing is uploadedFree, no sign-up

Build one

Decode a cron expression into plain fields and see its next ten run times in your timezone and UTC — including the day-of-month/day-of-week OR rule from crontab(5) that most tools quietly get wrong.

Reading an expression in one pass

ExpressionMeaning
*/5 * * * *every five minutes
0 * * * *on the hour, every hour
0 9 * * MON-FRI09:00 on workdays
0 3 * * SUN03:00 every Sunday — the classic backup slot
0 0 1 * *midnight on the first of the month
30 4 1,15 * 504:30 on the 1st, the 15th and every Friday — the OR rule

The mistakes worth knowing by name

The AND/OR trap is the one this page flags: restrict both day fields and they combine with OR, per crontab(5) — a rule so widely misimplemented that testing it is the fastest way to judge any cron library. The midnight-day boundary: 0 0 * * MON fires at the first second of Monday, not the last of Sunday. Steps start from the range's own start: */15 in the minute field means 0, 15, 30, 45 — but 5/15 means 5, 20, 35, 50.

Everything runs in your browser; expressions are not sent anywhere.

Frequently asked questions

What do the five fields mean?

In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC), day of week (0–7 or SUN–SAT, where both 0 and 7 are Sunday). Each field takes a value, a list (1,15), a range (9-17), a step (*/15), or combinations — 0 9 * * MON-FRI is nine in the morning on workdays.

What is the OR rule the tool warns about?

When BOTH day fields are restricted, crontab(5) fires on dates matching either one — not both. The man page's own example: 30 4 1,15 * 5 runs at 4:30 on the 1st, on the 15th, AND on every Friday. Tools and schedulers that AND the two fields silently run your job far less often than the crontab meant; this parser implements and flags the real rule.

Which timezone do the run times use?

Both. A crontab fires on its machine's wall clock, so the next-runs table shows each fire in your browser's timezone — treated as the machine's — and in UTC beside it. If your server runs in another zone, the pattern is the same: read the local column as that machine's clock.

What do @daily and the other shortcuts expand to?

@hourly is 0 * * * *, @daily and @midnight are 0 0 * * *, @weekly is 0 0 * * 0, @monthly is 0 0 1 * *, and @yearly/@annually are 0 0 1 1 *. They are exact synonyms — this tool expands them so you can see the five fields they stand for.

Why does the tool say my schedule never fires?

Because the date it names does not exist: 0 0 30 2 * waits for 30 February forever. The scanner searches far enough ahead to find any real schedule — 29 February gaps included — so an empty result is a genuine verdict, not a search that gave up early.

Does this cover Quartz or AWS six- and seven-field crons?

No — this is the five-field Vixie/POSIX dialect used by Linux crontab, GitHub Actions and most schedulers. Quartz adds a seconds field and ? / L / W symbols, and AWS EventBridge has its own variant; expressions from those need their own documentation. If your expression has six or seven fields, the count error you see is this distinction.

Related tools