# What is Dead Letter Queue?

Also called DLQ, dead letter.

A dead letter queue is a separate holding area for messages that could not be processed successfully after their retry attempts were exhausted. Moving failures aside keeps a poison message from blocking or endlessly recycling through the main queue, while preserving the payload for inspection. Items in a dead letter queue can be examined, fixed, and replayed once the underlying cause is resolved.

The problem it solves is the poison message. If an item fails deterministically, for example because it references a deleted record or fails to parse, retrying it will never succeed. Left in the main queue it consumes capacity indefinitely and, in strictly ordered queues, can block everything behind it. Routing it aside after a bounded number of attempts converts an ongoing failure into a finite, inspectable set.

A dead letter queue is only useful if someone looks at it. In practice these queues are often created and then never monitored, which turns them into a place where data quietly disappears. The queue needs an alert on depth or on any new arrival, ownership by a specific team, and a routine for triage, because a silent dead letter queue is functionally the same as discarding the message.

Useful entries carry more than the original payload. Recording the failure reason, the exception, the attempt count, timestamps, and correlation identifiers turns triage from guesswork into a lookup. Without that context, an operator holding only the original message must reconstruct what went wrong from logs that may already have aged out of retention.

Replay needs care. Reprocessing an item after a fix can duplicate side effects if some steps completed before the failure, so replay depends on the same idempotency that makes retries safe. Replaying a large accumulated batch at once can also overwhelm a dependency that has just recovered, so items are usually released at a controlled rate.

## Key points

- Holds messages that failed after retries were exhausted.
- Prevents poison messages from blocking or recycling forever.
- Alert on arrivals; an unwatched queue is silent data loss.
- Store failure reason, attempt count, and correlation ids.
- Replay requires idempotency and a controlled release rate.

## In practice

A synchronization job fails for one account because a required field is missing. After five attempts with increasing delays, the message moves to the dead letter queue along with the parse error and the account identifier, and an alert fires on the new arrival. An engineer identifies a schema change upstream, deploys a fix, and replays the twelve accumulated messages at a few per second so the recovering downstream API is not flooded.

## Related terms

- [Queue](/en/glossary/queue)
- [Retry policy](/en/glossary/retry-policy)
- [Exponential backoff](/en/glossary/exponential-backoff)
- [Idempotency](/en/glossary/idempotency)
- [Alerting](/en/glossary/alerting)

[Back to the AI Glossary](/en/glossary)