# Count resolved operations, not messages removed from the queue

A falling dead-letter count can mean replay, deletion or expiry. Measure the business outcome and unresolved age separately from transport movement.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Define resolution states

Use explicit outcomes such as completed, rejected with reason, superseded, repaired and awaiting reconciliation. Keep them linked to the original operation identity.

A message moved back to the source queue is in progress, not resolved. It may fail again or produce an uncertain effect.

Do not use queue emptiness as the sole completion condition for recovery.

## Track the oldest unresolved work

Measure age from the business operation's original acceptance where relevant, not only the latest queue enqueue time. Transport metadata can change during movement.

Show retention risk and the owner of unresolved categories. A small number of old messages can represent important customer work even when the overall queue is nearly empty.

Keep the platform's actual retention semantics documented for the chosen queue type.

## Measure replay quality

Track how many selected operations complete, fail again, require review or are rejected as obsolete. Observe duplicate effects through the application's reconciliation checks.

For an illustrative replay of 500 messages, 480 completed, ten still processing and ten returned to failure should remain those outcomes. Reporting 500 redriven describes movement only.

Record failure recurrence by cause so the team can see whether the underlying fix worked.

Check whether the outcome denominator is stable. If ten messages expire before classification, they have not become ten successful resolutions. Keep an explicit expired-without-confirmed-outcome category and escalate it according to the business consequence.

For a dispatch workflow, reconcile the selected operation IDs against confirmed dispatch records. This catches the opposite error too: one operation can produce two external effects while the queue reports one completed message. The reconciliation measure should detect both missing and repeated outcomes.

## Include current-service impact

Monitor live processing latency and downstream throttling during replay. A recovery that clears historical work while breaking current requests is not an unqualified success.

Measure net backlog reduction and the rate at which new failures enter the queue. The system may still be creating unresolved work faster than it resolves it.

Accept the recovery when selected operations reach known outcomes and normal service remains within its agreed limits. Queue metrics help locate work, while application evidence establishes what happened to it.

## Sources

- [Amazon SQS: dead-letter queues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)