Verify cron impact with persisted outcomes before and after recovery

A missing scheduler invocation establishes an execution gap, not a complete customer-impact list. Verify each proposed impact against persisted task outcomes, feature configuration, and delivery records. Separate no executions, overdue work, work processed with a skip, provider acceptance, and delivery. A task listed in a shared cron handler may also execute inline or in another worker; an unconfigured feature has no demonstrated affected work. Old failed or processing rows are not automatically outage backlog.

When a recovery run occurs during investigation, freeze the pre-recovery interval and inspect append-only run results alongside current task rows. Recurring tasks overwrite their last-run/next-run fields and completed one-shot jobs may be deleted, so current queue rows alone cannot reconstruct the outage. Recovery success at the HTTP level also does not establish every stage succeeded or every eligible record caught up. Limits: source and persisted outcomes can verify execution and observed backlog, but missing upstream records need provider comparison, and receipt status should not be overstated as driver action.