5 Real Cron Scheduling Bugs That Actually Happened

A billing job was scheduled with */45 * * * * on the reasonable-sounding assumption that it meant 'every 45 minutes.' It doesn't — cron step values only produce a true rolling interval when the step evenly divides the field's range, and 45 doesn't divide 60. The actual schedule was minute 0 and minute 45 of every hour: a 45-minute gap, then a 15-minute gap, repeating. A downstream batch job that assumed a consistent 45-minute window between runs ended up processing overlapping time ranges during the short gap, and a subset of transactions got billed twice.

The fix wasn't a scheduling change — it was recognizing that */45 never meant what it looked like it meant, and that any step value needs to be checked against whether it actually divides its field's range evenly before it's trusted to mean 'every N.'

A nightly job scheduled for 1:30 AM server-local time ran fine for months, then started running twice on one specific night and not at all on another, exactly twice a year. The server's local timezone observed daylight saving time, and cron has no awareness of DST at all — it just watches the wall clock. When clocks fall back, the 1:30 AM wall-clock time occurs twice, and cron dutifully fires for both; when clocks spring forward, 1:30 AM never occurs that day, and the run is silently skipped entirely.

The fix that actually holds up is running servers on UTC and scheduling cron in UTC too, then converting to local time only for display purposes — DST transitions become a non-event because UTC doesn't observe them.

A job meant to run on the last weekday of each month combined a day-of-month range with a day-of-week value, expecting cron to treat it as an AND condition where both must match. Standard cron's day-of-month and day-of-week fields are OR'd together whenever neither is a wildcard, so the job actually ran on every day matching either condition, producing extra runs on weekdays that had nothing to do with month-end.

This is one of the most consistently misunderstood parts of cron syntax, and the only reliable fix is knowing the OR-rule exists in the first place — when you need a true AND between day-of-month and day-of-week, the check has to move into the job itself.

A data-sync job ran every 5 minutes and was assumed to always be roughly current. After a routine kernel-update reboot took the server offline for about half an hour, nobody noticed the job hadn't caught up on the runs it missed — plain cron doesn't remember or replay anything it missed while the machine was off. The gap turned into a much larger reconciliation problem once it was finally noticed, because nothing had flagged that the sync had silently fallen behind.

anacron, for periodic jobs on machines that sleep or reboot, or a monitoring heartbeat that alerts when an expected run doesn't arrive, are the two practical fixes — either catch up automatically, or make the gap loud enough to notice immediately.

A team migrating standard cron expressions into a Quartz-based Java scheduler copied the 5-field expressions over as 6-field Quartz ones by just prepending a 0 for seconds, without noticing that Quartz requires exactly one of the day-of-month or day-of-week fields to be the literal ? character, and rejects expressions where both are concrete values. Every migrated job failed to parse, and because the deployment process didn't surface scheduler startup errors anywhere visible, the entire batch of previously-working jobs silently stopped running the moment the new deployment went live.

The fix is procedural as much as technical: treat a cron-format migration between platforms as a real conversion with its own validation step, not a mechanical field-count change, and add a startup check that fails loudly if any scheduled job didn't register successfully.