Common cron expression mistakes and time zone traps

Scheduled jobs (nightly sync, report, backup) are the quiet backbone of most integrations. Because a cron expression is short, its mistakes are easy to miss: the expression is valid, the job runs, but not when you expect. The traps below are the ones we meet most often with the standard five-field expression (minute, hour, day of month, month, day of week).

1. Day of month and day of week combine with OR

Reading "0 9 1 * 1" as "09:00 if the 1st is a Monday" is a common misreading. When both fields are restricted, classic (Vixie) cron combines them with OR: the job runs on the 1st and also every Monday. If one of them is a star, the logic goes back to AND. For a condition like "the first Monday of the month" the expression alone is not enough; the job has to check today's date itself.

2. A step value resets at the top of the hour

"*/7 * * * *" looks like every seven minutes; in reality the minutes are 0, 7, 14, ... 56, and then 0 again at the top of the hour. So the gap after 56 is 4 minutes. Steps that do not divide 60 (7, 8, 25...) run unevenly. If you truly need an even interval, pick a step that divides 60 (5, 10, 15, 20, 30) or build the scheduler on a "since last run" basis.

3. Months without a 31st

"0 0 31 * *" does not run every month, only in the seven months that have 31 days. For "month end", a safe day such as the 28th is usually chosen, or the job runs every day and checks whether tomorrow is the 1st. In February the 30th and 31st never exist, and the 29th only in leap years.

4. Time zone: what does the server say?

The time zone of a cron expression is the time zone of the environment the job runs in, which in most cloud environments is UTC. UTC 06:00 is 09:00 in Türkiye (UTC+3, no daylight saving). For "every morning at 09:00" on a UTC server the expression must be "0 6 * * *". When the environment changes (from a local machine to the cloud) the time zone changes too and the job shifts by three hours. So note next to the expression which time zone it was written in.

5. Daylight saving changes

In a time zone with daylight saving, one hour does not exist at the spring change: in Germany, for example, on the last Sunday of March local time jumps from 02:00 to 03:00, and "30 2 * * *" may not run that day. In autumn one hour happens twice and the same job may run twice. Behaviour depends on the scheduler. Countermeasure: schedule critical jobs in UTC, or write the job so that running it again does no harm (idempotent).

6. Other systems' syntax

Quartz and similar tools use six or seven fields with a seconds field, and special characters such as "?", "L" and "W". Pasted into standard cron, such an expression is invalid or means something else. For day of week, both 0 and 7 mean Sunday; names (MON, JAN) may not be supported everywhere.

See it before you run it

Type the expression into the cron expression explainer: it explains it in plain language, shows the next 10 run times for the time zone you choose and warns about traps like the OR rule. To convert timestamps there is the timestamp converter, and for retry behaviour the API retry simulator. To review your integration schedule, get in touch.