Short answer
A dead-letter queue (DLQ) is where an integration puts messages or jobs that could not be processed after a defined number of attempts, so they stop retrying but are not lost. It isolates "poison" messages that would otherwise block or endlessly retry, preserves them for investigation, and allows replay once the cause is fixed. A DLQ is only useful if someone monitors it and has a safe way to replay.
A dead-letter queue (DLQ) is a holding area for messages that an integration could not process. Rather than retrying forever or discarding them, the integration moves them aside, where people can see them, understand the problem, and replay them later.
Why integrations need one
Without a DLQ, failed messages end up in one of two bad places:
- Infinite retries, consuming capacity and filling logs, while possibly blocking messages behind them.
- The void: dropped after the last attempt, with only a log line as evidence.
A DLQ bounds retries and preserves the failure.
What to store
Each dead-lettered item should include:
- the original message or a reference to it,
- the resource and workflow (for example, order export for order 1042),
- attempt count and timestamps,
- the last error with full detail,
- the version of the code that processed it.
How to operate a DLQ
- Monitor it. Alert when items arrive, and when the oldest item exceeds an age threshold.
- Assign an owner. Developers for technical failures; business users for data issues if routed there.
- Investigate and fix the cause before replaying.
- Replay safely. Processing must be idempotent so replay cannot duplicate records. Re-fetch current data rather than reusing stale payloads where possible.
- Record resolutions. Mark items replayed, resolved manually, or discarded, with a reason.
Summary
A dead-letter queue stops failing messages from retrying forever while keeping them for investigation and replay. Store enough context to diagnose, monitor it actively, and make replay idempotent. See handling failed ERP synchronization jobs for a full workflow.
Frequently asked questions
What is a poison message?
A message that fails every time it is processed, usually because of bad data or a bug. Without a DLQ, it can retry forever or block messages behind it.
Do I need a message broker to have a DLQ?
No. Managed queue services such as Amazon SQS and Google Cloud Pub/Sub support dead-lettering natively, but a status value of "dead" in a database job table works the same way.
Should data errors go to the DLQ?
Many teams separate them. Data errors that business users can fix go to a review queue; unexpected technical errors go to the DLQ for developers. Both need owners and alerts.
Sources and further reading
Platform-specific statements on this page were checked against these sources on . Vendor APIs change; confirm details in the current documentation before you build.
- [1] Amazon SQS dead-letter queues — Amazon Web Services
- [2] Google Cloud Pub/Sub dead-letter topics — Google Cloud
- [3] Enterprise Integration Patterns — dead letter channel — Gregor Hohpe and Bobby Woolf
Related reading
- Guides How to Handle Failed ERP Synchronization Jobs What to do when integration jobs fail — triage categories, dead-letter queues, review screens, safe replay, ownership, and the alerts that prevent silent data loss.
- Concepts What Are Retry Strategies? How integrations retry failed operations — immediate, fixed, exponential backoff, jitter, Retry-After, attempt limits, and circuit breakers — and which errors to retry.
- Guides How to Implement Retries and Idempotency A practical implementation of retries with exponential backoff and jitter, plus idempotency keys, so ecommerce-ERP integrations can retry safely without side effects.
- Concepts What Is Integration Monitoring? What integration monitoring covers, how it differs from application monitoring, the key metrics for ecommerce-ERP integrations, and how it prevents silent data loss.