Cron Mistakes: Common Syntax errors and server timezone offsets

The day-of-month / day-of-week OR trap

The single most common cron mistake: assuming that setting both day-of-month and day-of-week restricts a job to their intersection. Most cron implementations actually OR the two fields when both are non-wildcard — 0 0 15 * 1 runs at midnight on the 15th or every Monday, not only on Mondays that happen to fall on the 15th. If you need a true AND condition, it has to be enforced in the job's own logic, not the cron expression.

Timezone assumptions

Cron itself has no inherent timezone awareness — a schedule runs according to whatever timezone the executing system's clock is set to, which for many servers defaults to UTC, not the timezone the person writing the schedule was thinking in. A team assuming "9 AM" means their local 9 AM can be off by several hours if the server (or cloud scheduler's configured timezone) doesn't match. Around Daylight Saving Time transitions, a schedule using local time can also run twice or skip entirely on the transition day — a subtle bug that only surfaces twice a year.

Off-by-one field confusion

Mixing up field order (minute-hour vs. hour-minute) is a classic copy-paste error — 9 30 * * * (minute 9, hour 30 — invalid, since hours only go to 23) versus the intended 30 9 * * * (9:30 AM). Some schedulers reject clearly invalid values outright; others silently interpret an out-of-range value in unexpected ways, so the mistake isn't always caught immediately.

Assuming */N always divides evenly

As covered in Cron Expression Every 5 Minutes, step values that don't evenly divide their field's range (*/7 in minutes, */13 in hours) wrap around unevenly at the boundary — a gap that's easy to miss without explicitly checking the generated run times.

Silent failures with no monitoring

Cron jobs fail silently by default — if a job errors out or a script has a bug, cron doesn't retry, alert, or surface the failure anywhere unless the job itself logs to somewhere monitored, or the crontab explicitly redirects output and errors are checked. "It's scheduled" is not the same as "it's confirmed to run successfully."

Common mistakes, summarized

• Assuming day-of-month AND day-of-week when both are set — most implementations OR them.
• Ignoring the executing system's timezone, especially around DST transitions.
• Swapping field order (minute/hour) from memory instead of double-checking against the five-field reference.
• Trusting */N step values without confirming they divide evenly into the field's range.
• Deploying a schedule with no logging or alerting, so failures go unnoticed indefinitely.

FAQ

Why did my cron job run on a day I didn't expect?
Likely the day-of-month/day-of-week OR behavior — check whether both fields are restricted and reconsider whether that's actually what you want.

Does cron account for Daylight Saving Time automatically?
Only if the scheduler is explicitly configured with a timezone that observes DST and handles the transition — a naive local-time schedule can run twice or be skipped on the transition day.

How do I catch a silently failing cron job?
Redirect the job's output/errors to a log file or monitoring system explicitly — cron itself won't alert you to a failure unless you set that up.

Catch expression mistakes before deploying with the Cron Expression Descriptor — it shows exactly what an expression means and when it will next run.