Dead letter recovery

Give every failed-message category a resolution owner

Some failures need code changes, others need a business decision. Route them deliberately so the queue does not become an unowned archive.

In this article

Publish the classification map

Describe the main failure categories and the team responsible for each. Include transient dependency failure, unsupported contract, invalid business input and unknown external effect.

For each category, state the evidence needed before retry or closure. Avoid a universal instruction to redrive after the next deployment.

Keep the map close to the operational queue view and runbook.

Explain the recovery controls

Show how to inspect a safe sample, select a bounded scope, set replay rate and stop further movement. State what already moved work may continue doing.

Separate payload inspection and replay permissions where the effect requires it. Keep sensitive details behind the appropriate access boundary.

Record operation identity and original age so transport changes do not obscure the business history.

Hand over retention risk

Document queue and evidence retention under the actual platform and type. Assign a review cadence that leaves time to resolve important work before expiry.

A retention extension should be a deliberate choice with a purpose, not the only response to a growing backlog.

Keep intentionally closed operations distinguishable from messages that disappeared through expiry.

Use a concrete state summary during the exercise. For example, twelve operations await recovery, eight have confirmed dependency failures, three have unknown external outcomes and one was superseded by a customer cancellation. The receiving team should replay only the eligible group after the dependency fix and assign the other decisions appropriately.

Record where that classification lives and how it is updated. If it exists only in the outgoing engineer's chat message, a later bulk redrive can ignore the distinction. The durable recovery view should preserve the reasoning at the operation level.

Rehearse two different outcomes

Have the receiving team recover a synthetic transient failure and separately handle an operation whose external effect is uncertain. Verify that they choose different paths.

Then show an obsolete command and confirm that they can record a valid decision not to execute it.

The handover is complete when failed work can reach a known outcome through the right owner. The queue should help the organisation recover business operations, not merely collect messages that are too difficult for the normal worker.

Primary sources

Amazon SQS: dead-letter queues

References checked 11 September 2026.