Cron Expression Explainer

The mistake almost everyone makes

When you restrict both day-of-month and day-of-week, cron runs on a day matching either — not both.

So 0 0 1 * MON is not "midnight on Mondays that fall on the 1st". It is "midnight on the 1st of every month, and midnight every Monday" — roughly five times more often than intended. This is genuine POSIX behaviour, not a quirk of one implementation, and it is the commonest reason a job fires more than its author expected.

If you genuinely need both conditions, cron cannot express it. Schedule the looser one and check the date at the top of your script.

Field reference

• * — every value
• */5 — a step: every 5th value, starting at the lowest
• 1-5 — a range
• 1,3,5 — a list
• 0-30/10 — a step within a range: 0, 10, 20, 30
• MON, JAN — three-letter names, in the day and month fields

Sunday is both 0 and 7, which is why 5-7 means Friday, Saturday and Sunday.

Time zones

The times above are your device's local time. Cron runs in the server's time zone, which is very often UTC, and it does not adjust for daylight saving in a way that guarantees a job runs exactly once — a schedule inside the shifted hour can be skipped or repeated depending on the implementation. For anything where running twice matters, make the job safe to run twice rather than relying on the schedule.

This tool does the parsing, not the classification: it tells you what a valid expression means, and it deliberately declines the non-standard extensions (L, W, #, ?, seconds fields) that some schedulers add. Claiming to read those and getting them subtly wrong would be worse than saying no.