2026-06-27 · 6 min read · Rahul Chitturi
- cron
- reliability
- debugging
A scheduled job that appears to run twice can create duplicate emails, payments, cache invalidations, or cleanup work. The schedule may be wrong, but the more common causes are retries, overlapping executions, deployment races, or logs that group two different windows together.
Treat the incident as a data problem first. Reconstruct what was scheduled, what actually started, and which inputs each run processed before disabling the job entirely.
Identify the run window
Every scheduled task needs a window or run ID that is independent from the wall clock time when the function starts. Without that, a retry looks like a second job and an overlapping slow run looks like a scheduler bug.
- scheduled_for: the intended processing window
- started_at: the platform invocation time
- attempt: retry number or execution ID
- idempotency_key: the value used to dedupe side effects
Check retries and overlap separately
Retries usually follow a failure or timeout. Overlap happens when the next scheduled tick starts before the previous run finishes. Both can be valid platform behavior, so production jobs should be safe to run more than once for the same window.
If the job talks to external APIs, persist a dedupe key before the side effect. If the job scans database rows, mark the processed window rather than relying only on current time.
A Flashman workflow
Preview the cron expression, convert timestamps from logs into the same timezone, format JSON event payloads, and diff the deployed schedule against the expected config. That gives you evidence before changing retry settings.
The long-term fix is usually a clearer run contract: one schedule, one timezone, one idempotency key, and logs that make duplicate attempts obvious.