Skip to tool
ecech.
💻 Developer & Code

Cron Parser That Gets the Day-of-Month and Day-of-Week Rule Right

Reads a cron expression in plain English and shows the next ten run times — including the OR rule that makes 0 0 13 * 5 fire 36 times more often than intended.

Field by field

Next ten runs

Advertisement

How the calculation works

0 0 13 * 5 is not “Friday the 13th” What people expect day-of-month 13 AND Friday 1.75 days a year on average What cron does day-of-month 13 OR Friday 5.2 days a month on average Either field matching is enough. 36 times as many runs as intended, from an expression that looks right.

How to Use This Tool

Type a cron expression. You get each field in plain English, the next ten times it will actually fire, and a warning if it can never fire at all.

The rule that catches everyone

A cron line has five fields: minute hour day-of-month month day-of-week. Four of them combine the way you would expect — all conditions must hold. The two day fields do not.

If both the day-of-month and day-of-week fields are restricted — that is, neither is * — the job runs when either matches. This is the documented behaviour of POSIX cron and of Vixie cron, which is what almost every Linux system runs.

So 0 0 13 * 5 does not mean “midnight on Friday the 13th”. It means “midnight on the 13th of every month, and also midnight every Friday”. Counted over twenty years that is 5.2 runs a month, against the 1.75 Friday-the-13ths a year the author meant — the job fires about 36 times more often than intended. The expression is valid, the intention is obvious, and nothing warns you.

If either day field is * the rule does not apply and everything behaves normally. That is why the problem stays hidden: the common expressions are all fine, and only the ones people write deliberately go wrong.

January 2026 under 0 0 13 * 5 MT WT FS S 2 9 13 16 23 30 five Fridays plus the 13th, which is a Tuesday Six runs in a month where the author expected none. The 13th falls on a Friday only 1.75 times a year.
Verified against the calendar: January 2026 begins on a Thursday, so the 13th is a Tuesday.

Schedules that can never fire

0 0 31 2 * is perfectly valid cron. February has never had a 31st and never will, so the job will never run. Same for 0 0 30 2 *. A checker that only reports “valid” has answered the wrong question — this one searches forward and tells you when it finds nothing.

Two things this does not model

  • Time zones and DST. Cron runs in the server's local time. When the clock jumps forward, a job scheduled inside the skipped hour may not run at all; when it goes back, it may run twice. The preview here uses your browser's clock and does not simulate that — if your job runs between 01:00 and 03:00, check what your specific cron implementation does.
  • Non-standard extensions. L, W, # and seconds-resolution fields belong to Quartz and to some language libraries, not to system cron. They are rejected here rather than guessed at, because guessing which dialect you meant is how a scheduler ends up firing at the wrong time.
Advertisement

Frequently Asked Questions

What does 0 0 13 * 5 mean in cron?
Midnight on the 13th of every month, and also midnight every Friday — not Friday the 13th. When both the day-of-month and day-of-week fields are restricted, cron runs when either one matches. That is documented POSIX and Vixie cron behaviour, and it turns an expression people expect to fire once or twice a year into one that fires about nine times a month.
How do I actually schedule Friday the 13th?
Not with a single cron expression, because the OR rule makes it impossible. The usual approach is to schedule 0 0 13 * * — every 13th — and have the script itself check whether today is a Friday and exit if not. Putting the AND condition in the job rather than in the schedule is the only reliable way.
Why does my cron job never run?
One common cause is a date that does not exist: 0 0 31 2 * is valid syntax for 31 February. Another is the OR rule firing far more often than intended and someone disabling the job. This tool searches forward through several years and tells you explicitly if it finds no matching time.
What are the five cron fields?
Minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where both 0 and 7 are commonly accepted as Sunday). Each accepts a single value, a list like 1,15, a range like 9-17, a step like */15, or a combination.
Does this handle L, W and # syntax?
No, and it rejects them rather than guessing. Those belong to Quartz and to some language-specific libraries rather than to system cron, and the dialects disagree about what they mean. Guessing which one you meant is how a scheduler ends up firing at the wrong time.
Does it account for daylight saving time?
No. Cron runs in the server's local time, and when the clock jumps forward a job scheduled inside the skipped hour may not run while one scheduled during a repeated hour may run twice. This preview uses your browser's clock and does not simulate those transitions. If your job runs between 01:00 and 03:00, check what your cron implementation does.

Related tools in Developer & Code

Browse all Developer & Code tools
The Mac mini the ecech. site is built on, beside a handwritten note reading ecech.com.

Made by one person

ecech. is not a content farm. Every tool here is written and checked by hand, one at a time, by someone who wanted the tool to exist and could not find a version that showed its working.

No accounts and no sign-in, and nothing you type reaches a server — every calculation on this page runs inside your browser. The ads are served by Google and do set their own cookies, which is set out in full on the privacy page. More about the site.