AWS SQS & SNS Support
SQS dead-letter queues and redrive.
A dead-letter queue catches messages your consumer fails to process, so one bad message does not loop forever or vanish. A DLQ nobody watches is just a quiet failure. We configure it correctly, alert on it, find out why messages land there, and redrive them once fixed.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Messages keep reappearing or are retried endlessly
- Messages disappear after the retention period with no record
- A bad message blocks processing, especially on FIFO queues
- A DLQ has messages and nobody knows why
- You fixed a bug and need to reprocess failed messages
What you get
- Redrive policy and DLQ settings in infrastructure as code
- An alarm and runbook for DLQ messages
- Root cause for the current dead-lettered messages
- A tested redrive procedure
How we do it
A clear, safe process you can follow along with.
1. Check the queue configuration
We read the source queue's redrive policy: the DLQ ARN and maxReceiveCount. A DLQ must be the same queue type as the source and live in the same account and Region.
2. Choose maxReceiveCount deliberately
Too low and transient errors send good messages to the DLQ. Too high and bad ones are retried for a long time. With Lambda event source mappings we account for the retries Lambda does before a message becomes visible again.
3. Set retention on the DLQ
A message's original enqueue time continues counting in the DLQ, so the DLQ retention should be longer than the source queue's. Otherwise messages can expire soon after arriving.
4. Alarm on DLQ depth
We create an alarm on ApproximateNumberOfMessagesVisible for the DLQ, routed to SNS, email or chat, so failures are seen the same day.
5. Diagnose why messages failed
We read sample messages in the console, correlate with consumer logs by message ID and fix the real cause: bad payload, bug, downstream outage or permission issue.
6. Redrive after fixing
The console and the StartMessageMoveTask API can move messages from the DLQ back to the source queue or another destination. We redrive at a controlled rate so the fixed consumer is not overwhelmed.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
No DLQ at all
Poison messages cycle until retention expires and then vanish.
DLQ retention shorter than the source
Messages can expire in the DLQ almost immediately.
Redriving before fixing the bug
The same messages simply fail again.
Mixing FIFO and standard
The DLQ must match the source queue type.
Frequently Asked Questions
What does maxReceiveCount mean?
It is the number of times a message can be received without being deleted before SQS moves it to the dead-letter queue.
Can I move messages from the DLQ back to the original queue?
Yes. SQS supports redrive from the console and API, and you can choose the destination and the rate.
Does the DLQ need its own DLQ?
Not normally. The DLQ is a holding place for investigation, so we alarm on it rather than chaining another queue.
Want Help With SQS dead-letter queues and redrive?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required