2026-07-16 · 6 min read · Rahul Chitturi
- cron
- production
- debugging
Duplicate scheduled jobs usually show up as double emails, repeated billing attempts, or two workers racing through the same queue. The visible symptom is a business event, but the cause may be a cron expression, a retry policy, a deployment overlap, or a missing idempotency key.
Before disabling the schedule, identify whether the duplicate came from two planned runs, one run plus a retry, a manual backfill, or two environments using the same production credentials.
Separate schedule time from execution time
A cron expression describes when work should start. The worker may begin late, retry later, or continue past the next scheduled window. Logs should record both the intended schedule timestamp and the actual execution timestamp.
- Preview the cron expression around timezone and daylight-saving boundaries
- Convert scheduler timestamps and worker logs into the same timezone
- Check whether retries reuse the original job ID or create a new event
- Confirm locks expire safely when a worker crashes mid-run
Use idempotency evidence
A safe job can run twice without applying the side effect twice. That usually means a stable idempotency key, a unique database constraint, or a processed-event table keyed by the business object and schedule window.
When investigating, diff the deploy that changed scheduler ownership, retry settings, lock TTL, or queue visibility timeout. Small infrastructure changes often explain duplicates better than the job body itself.
A Flashman workflow
Use the cron parser to preview planned runs, the timestamp converter to align logs, the UUID generator for safe sample job IDs, and the diff tool to compare scheduler configuration before and after the incident.
Document the recovery path separately from the prevention fix. Backfills and dedupe scripts need their own safety checks so the cleanup does not create another duplicate event.