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:
1. Browse failed events with filters by endpoint, error type, time range 2. Inspect individual events to understand why they failed 3. Replay single events or bulk replay after fixing the underlying issue 4. 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.