2026-09-06 · 6 min read · Rahul Chitturi
- cron
- scheduling
- reliability
When a scheduler or worker is unavailable at a planned time, platforms differ on whether the run is skipped, started once after recovery, or replayed for every missed interval. That misfire behavior can create a silent data gap or a burst of stale work.
Changing the cron expression does not resolve a recovery policy that was never defined.
Build a single execution timeline
Record nominal schedule times, scheduler availability, dispatch events, queue receipt, worker starts, completion, retries, and deadlines in UTC. Distinguish a schedule that was never evaluated from a dispatched job that later failed.
- Confirm timezone and daylight-saving behavior
- Find platform catch-up and starting-deadline settings
- Check concurrency and history retention limits
- Include manual runs and failover events
Choose policy from business meaning
A billing close may require controlled backfill, while a frequent cache refresh may safely skip old intervals. Define the maximum useful age, ordering, duplicate behavior, and capacity available after a long outage.
Give every logical interval a durable idempotency key. Bound catch-up volume and use queues or rate limits so recovery does not overload the same dependency that caused the outage.
A Flashman workflow
Use the cron helper to enumerate nominal times, timestamp converter to align logs, UUID generator for synthetic run keys, JSON formatter for scheduler events, and diff for configuration revisions.
Test short and long outages, restart at a boundary, duplicate dispatch, stale deadlines, overlapping recovery, daylight-saving transitions, queue saturation, and manual backfills.