How to Debug a Cron Job That Silently Skips Its DST Run
Описание и применение
Проблема с cron‑заданием, которое пропускает или дублирует запуск во время перехода на летнее/зимнее время. Решение включает проверку часового пояса, добавление идемпотентности, перенос критических задач в безопасное время и написание регрессионных тестов.
Задача
A cron job scheduled at 2:30 AM local time runs reliably most of the year but twice a year either skips or runs twice due to daylight‑saving‑time transitions.
Результат
The job now runs once per day, with idempotent safeguards, clear documentation, and automated tests ensuring correct behavior across DST transitions.
Рабочий процесс
- Confirm cron interprets schedules in local time, not UTC.
- Identify whether the issue occurs during spring‑forward or fall‑back by checking logs and DST transition dates.
- Read the scheduler’s documentation on DST behavior to understand its default handling.
- Add idempotency to the job to guard against duplicate runs during fall‑back.
- Avoid scheduling critical jobs inside the 1:00‑3:00 AM window; move them to a safer time like 5:00 AM.
- Write regression tests that simulate the transition dates and assert exactly one run.
- Document the chosen behavior next to the cron configuration for future engineers.
Доказательства
A recurring job scheduled for 2:30 AM local time runs reliably for months, then twice a year it either doesn't run at all or runs twice back to back.
Spring-forward (an hour skips, e.g., 2:00 AM jumps straight to 3:00 AM) and fall-back (an hour repeats, 1:00-2:00 AM happens twice) produce different symptoms.
- Дата записи: 2026-09-12T20:30:58.709Z