Cron Expression Parser

Five fields, no year, and a great deal of trust

A cron expression is five numbers standing in for a sentence, and it goes wrong in ways nothing warns you about: the daemon accepts anything syntactically legal and runs it quietly for months. This tool reads one back in English, lists the next times it will fire, and counts how often that is over a year.

The fields are minute, hour, day-of-month, month and day-of-week, in that order. There is no year field and no seconds field, so every standard expression repeats forever: a single run on a fixed date is not something crontab can say, and a six-field expression belongs to Quartz or Spring instead.

Names work in the last two fields: JAN through DEC and SUN through SAT, so 30 8 * * MON-FRI is the schedule 30 8 * * 1-5. Sunday answers to both 0 and 7.

The 13th or a Friday, never both required

When day-of-month and day-of-week are both narrowed, cron combines them with OR rather than AND. So 0 0 13 * 5 is not Friday the 13th; it is midnight on every 13th and on every Friday. Asked for the next five runs after Saturday 15 August 2026, it answers 21 and 28 August, 4 and 11 September, then Sunday 13 September — four Fridays and a Sunday.

Across a year that expression fires 62 times: 52 Fridays plus 12 thirteenths, less the two dates that are both. An AND reading would fire twice. Leave either field as * and the OR never applies: 0 0 13 * * gives the expected 12 runs, 0 0 * * 5 gives 52.

Friday the 13th therefore has no expression in standard cron. The usual answer is to fire on every 13th and let the job check the weekday itself, with a one-line guard at the top of the script.

Two schedules a single character apart

Compare 0 0 * * 0, which runs 52 times a year, with * * * * 0, which runs every minute of every Sunday: 1,440 times a day and 74,880 times a year. The only difference is an open minute and hour field, and nothing complains until the logs fill up.

Steps count from the bottom of the field and restart at its boundary rather than running continuously. So */15 gives minutes 0, 15, 30 and 45, or 96 runs a day, while */7 gives 0, 7, 14 and on to 56 before jumping back to 0 — a four-minute gap across every hour boundary. A list is different again: 5,10 fires twice an hour, five minutes apart.

In the month field a step counts from January, so 0 0 1 */3 * means January, April, July and October rather than every three months from today: from August 2026 its next run is 1 October.

Dates that never arrive, and clocks that move

An entry of 0 0 31 * * fires in seven months a year, skipping April, June, September and November without comment. One of 0 0 29 2 * survives on leap years alone: after August 2026 its next runs are 29 February 2028 and 2032. The search looks eight years ahead and returns nothing at all when nothing matches, which is the honest answer for 0 0 30 2 *.

Cron fires on wall-clock time in whatever zone the daemon runs in, so the list can be read as UTC or against your own offset. That matters twice a year: a 02:30 job may be skipped when the clocks spring forward and run twice when they go back. Anything scheduled between 01:00 and 03:00 is worth moving; a UTC host is immune.