2026-07-06 · 6 min read · Rahul Chitturi
- cron
- jobs
- debugging
A missed cron run tempts teams to click rerun immediately, but the wrong backfill can double-send emails, reopen billing windows, or overwrite data. The safer path is to identify whether the schedule missed, the job started and failed, or a lock prevented execution.
Build a small incident timeline from the cron expression, platform logs, and job metadata before deciding how to backfill.
Confirm the expected run time
Start with the cron expression and the scheduler timezone. A job that appears missed in local time may have run correctly in UTC, or a weekday expression may skip a holiday deployment window. Generate the next run times around the incident instead of reading the expression from memory.
- Record the timezone used by the scheduler
- Compare expected_for with started_at and completed_at timestamps
- Check daylight saving boundaries for local-time requirements
- Verify that preview or staging schedules are not being mistaken for production
Separate scheduling from execution
A platform can trigger the job while the application still exits early. Look for deploy restarts, cold starts, expired secrets, queue backpressure, and distributed locks. If the job logs a run ID but no work happened, debugging the cron expression alone will not fix the next run.
- Lock already held: another worker may still be processing
- Retry exhausted: the platform may have stopped before app-level retries
- Secret or API error: the schedule fired but dependencies rejected work
- Input window empty: the job ran but selected no records
Backfill with idempotency
Before rerunning, decide the exact data window to process and how duplicate work will be ignored. Idempotency keys, processed markers, and dry-run counts make the difference between a safe catch-up and a second incident.
If the missed job sends notifications or charges customers, run the smallest verifiable window first and compare output with the expected count.
A Flashman workflow
Use the cron parser to preview expected runs, the timestamp converter to align logs, and the JSON formatter to inspect scheduler payloads or run records. Diff the failing deployment config against the last known-good version before changing job code.
Keep production data out of shared debugging notes. Redact customer IDs, use counts where possible, and document the chosen backfill window so the next incident starts with a known playbook.