What is a dead letter queue?
A dead letter queue is where a message goes when it cannot be processed and its retries are exhausted. The message is preserved with the reason for the failure, which turns the failure into a visible item of work. Without one, an unprocessable message is either discarded or retried indefinitely.
Also called: Dead letter channel
Why a failure with nowhere to go becomes a silent loss
The expensive version of this problem is quiet. A message fails validation and the handler discards it, after which the business learns weeks later that a batch of instructions never arrived. A dead letter queue converts that loss into a queue depth somebody is accountable for, which is a far cheaper thing to discover. It is also the clearest early signal of an upstream contract that changed without notice.
- A preserved failure can be examined, where a discarded one cannot.
- Queue depth makes an upstream change visible within hours.
- Indefinite retries consume capacity and conceal the underlying defect.
- Each retained message carries the context needed to process it later.
How a dead letter queue works
- A retry policy is defined with a finite attempt count and a growing interval.
- Messages exhausting that policy are moved to the dead letter queue intact.
- The failure reason and the attempt history are attached to the message.
- Queue depth is monitored with an alert threshold and a named owner.
- Each message is diagnosed before it is processed again or discarded, with that decision recorded.
- Anything processed again passes through the same idempotency checks as the original.
How a dead letter queue is evaluated
The queue is assessed on whether anything inside it is actually resolved. Measure the following over a settled period:
- age of the oldest message in the queue
- proportion of messages resolved successfully after diagnosis
- distribution of failure reasons across the queue
- time from arrival in the queue to an owner acknowledging it
- messages discarded without a recorded decision
Limitations, risks and common failure modes
- The queue accumulates for months because no owner was ever named.
- Messages are resubmitted in bulk without diagnosing what rejected them.
- Failure reasons are captured as a stack trace with no business context.
- Personal data in retained messages outlives the retention policy of its source system.