2026-07-20 · 6 min read · Rahul Chitturi
- cron
- production
- debugging
Daylight-saving transitions can make a scheduled job appear skipped, duplicated, or late depending on the scheduler timezone and the logs you read. A rushed backfill can then create the real incident by replaying work that already happened.
Treat DST investigations as schedule math plus idempotency evidence. You need to know which windows should have run, which windows actually ran, and whether replaying a window is safe for the side effects involved.
Preview the transition window
Do not rely on memory for daylight-saving behavior. Preview the cron expression around the transition in the scheduler timezone, then convert job logs into the same reference timezone before deciding what is missing.
- Record the intended schedule timestamp and actual execution timestamp separately
- Check whether the scheduler uses UTC, server local time, or a configured timezone
- Identify duplicated local hours and skipped local hours explicitly
- Compare deploy, retry, and manual-run events against the same time window
Backfill only with dedupe evidence
A safe backfill has a bounded window, a dry-run count, and an idempotency key that prevents duplicate side effects. If the job sends email, charges cards, or mutates external systems, prove the dedupe guard before replaying production work.
When the schedule was wrong, diff the old and new cron expression next to the incident timeline. That makes it easier to separate DST behavior from unrelated deploy or retry changes.
A Flashman workflow
Use the cron parser to preview runs, the timestamp converter to align logs, the diff tool to compare scheduler config, and the UUID generator for safe sample job identifiers in runbooks.
Close the incident with a replay checklist: timezone, expected windows, observed windows, skipped windows, duplicate windows, dedupe key, dry-run output, and the final backfill command.