Cron Expression Parser

Five fields, or six when the first one is seconds: minute, hour, day of month, month, day of week. Reading one is mostly mechanical. One rule inside it is not, and it is the rule that makes schedules misfire.

The two day fields are OR, not AND

0 0 13 * FRI does not mean Friday the 13th. When both the day-of-month and day-of-week fields are restricted, cron fires on any day matching either — so that expression runs on the 13th of every month and on every Friday, roughly sixty times a year instead of one or two. This is Vixie cron's behaviour, which is what crontab, most container schedulers and Cloudflare's own triggers implement. Whenever both fields are set, the output says so before it says anything else.

A cron expression has no timezone

There is no field for one. Run times here are computed in UTC and shown with your local equivalent beside them, labelled — but what your own server does depends on how that machine is configured, which the expression cannot tell you and this page will not guess.

Steps are not always what they look like

*/15 in the minutes field is 0, 15, 30, 45. 5/15 is 5, 20, 35, 50 — a bare value with a step starts there and runs to the end of the range. And 0,15,30 is a list, not a step: it stops before the end of the hour, so it is described as three times rather than as "every 15 minutes".

@daily expands to 0 0 * * *. 0 0 29 2 * next fires on 29 February 2028 — found by stepping days rather than seconds, which is why a four-year gap costs nothing. 0 0 30 2 * returns no runs at all, because 30 February does not occur.