The short answer
Freeze the loss window from queue configuration and observed timestamps, gather independent producer, transport, consumer, provider, local-record, external-effect, and monitoring evidence, generate candidate business-action identities from each source, deduplicate without erasing conflicts, classify confirmed lost, possibly lost, processed elsewhere, duplicate, excluded, and unknown, then reconcile consequences and record the residual blind spot.
Key takeaways
- The current DLQ count is not the historical denominator.
- Use independent sources on both sides of the queue.
- Unknown remains a valid outcome after honest reconstruction.
Establish the loss window from actual retention semantics
Record source/DLQ type, retention settings and versions, movement behavior, original versus DLQ timestamps, purge/delete events, oldest-message metrics, deployment changes, and observation gaps. Preserve screenshots as supporting evidence, not the denominator.
AWS documents that standard-queue expiry stays tied to original enqueue time while the DLQ age metric can reflect movement time; FIFO differs. Verify the deployed provider and queue type.
Triangulate independent populations
| Source | Candidate evidence | Blind spot | Join key |
|---|---|---|---|
| Producer | Event/action creation logs | May not prove enqueue | Event/business identity |
| Transport | Metrics, traces, retained metadata | May omit body or business result | Message/correlation ID |
| Consumer/local | Receipts, errors, object changes | Missing event may leave nothing | Event/object identity |
| External provider | Outcome and provider events | May lack local context | Provider/business identity |
Disposition candidates without false precision
Use confirmed lost, possible loss, processed by another path, duplicate representation, excluded with evidence, and unknown. Inspect all high-consequence candidates and a reproducible sample of exclusions.
Do not synthesize payload content that no source retains. Reconstruct only supported identity, timing, scope, and consequence.
Close with a reconstructed denominator and explicit residual blind spot
Name the population, cutoff, evidence version, owner, decision, unresolved exceptions, next checkpoint, and downstream records updated. Preserve the earlier state rather than replacing it with a clean current screen.
Reopen the record when a late event, changed source, new affected item, or downstream consequence invalidates the signed conclusion.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Queue contract/version frozen
☐
Loss window supported
☐
Independent sources collected
☐
Stable join keys used
☐
Duplicates retained then resolved
☐
High-consequence candidates inspected
☐
Unknowns reported
☐
Retention/monitoring corrected and retested
0 of 8 marked
Edge cases
- Metric resets during deployment: use multiple evidence sources.
- External effect exists without payload: reconcile the effect while keeping content unknown.
- Purge was authorized but population was not recorded: preserve the governance failure separately.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
1. Primary source · Amazon Web Services
Setting up dead-letter queue retention in Amazon SQSFor SQS, retention and age semantics differ by queue type and may not reveal original event age.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
Continue the workflow
Webhook dead-letter queue ownership and dispositionReconstruct an AI incident population when logs are incompleteWebhook replay reconciliation for property workflowsRevision history
2026-09-18
Initial Phase 6 operational article with distinct intent, original artifact, source limits, and AI-assisted technical review.