In any event-driven system, failures are inevitable. Networks go down. Services crash. Endpoints become unreachable. The question isn't whether events will fail to deliver — it's what happens when they do.
What is a dead-letter queue?
A dead-letter queue (DLQ) is where events go when they've exhausted all delivery attempts. Instead of being silently dropped, failed events are stored in a separate queue for inspection, debugging, and replay.
Why you need one
Without a DLQ, failed events disappear. You might not even know they failed. A customer's order confirmation never arrives. A partner's inventory update is lost. A critical alert is swallowed.
With a DLQ, every failed event is preserved with full context:
- The original event payload
- Delivery attempt history (timestamps, response codes, error messages)
- The target endpoint configuration at time of failure
- Routing rules that were applied
Inspecting and replaying
The real value of a DLQ isn't just storage — it's the ability to fix the problem and replay events. In Queuey, you can:
- Browse failed events with filters by endpoint, error type, time range
- Inspect individual events to understand why they failed
- Replay single events or bulk replay after fixing the underlying issue
- Set up alerts when DLQ depth exceeds thresholds
DLQ anti-patterns
- Ignoring the DLQ: If nobody monitors it, it's just a data graveyard
- Infinite retention: Set retention policies. Events from 6 months ago are rarely actionable
- No replay mechanism: A DLQ without replay is half a solution
How Queuey handles it
Every Queuey endpoint automatically gets a DLQ. Failed events are stored with full delivery context. You can replay events with one click, and set up Slack or email alerts when failures exceed your thresholds.