Inspect and Redrive DLQ Messages
Inspect individual AWS SQS dead-letter messages, selectively send them to a compatible destination queue, or run an AWS-native whole-queue redrive.
Use Tarmac to inspect and filter AWS SQS dead-letter queue messages before you decide whether to send individual messages back or redrive the whole queue.
How DLQs appear in the list
Any queue named as another queue's dead-letter target is grouped under Dead-letter in the queue list, and the DLQ type filter matches it. When you select a DLQ, Tarmac calls ListDeadLetterSourceQueues to resolve which queues feed it. Queue redrive can then default to the original source even when that source is not in your current list. Staged Send can target only compatible queues in the list.
Selective send
Selective work uses Send, not a hidden redrive action. Known source queues appear first and are labeled, and the first compatible destination is selected by default. Check it before you stage. Enable Delete originals after successful send only when the original DLQ messages should be removed after AWS confirms each copy. The option is available only while every selected message still has a live receipt.
Send works one message at a time, which is what makes it surgical. You pick the individual messages that deserve another chance, inspect them first if you want, and leave the rest.
Send and delete are separate calls. If the send succeeds and the delete fails, the message exists in both queues, and the action reports that the original was not deleted. Treat that as ordinary at-least-once redelivery. See SQS Essentials.
Fix the consumer before you redrive
A redriven message that hits the same bug lands right back in the DLQ, with a higher receive count. Inspect the DLQ, identify the failure class (facets on error fields make that fast), deploy the fix, then redrive. Redrive is the last step of an incident, not the first.
Queue redrive
Selective Send is for messages you filtered, inspected, and chose. Queue Tools ▸ Queue Redrive is for the whole DLQ.
Queue redrive uses AWS StartMessageMoveTask. It runs server-side and needs no receipt handles. Leave the destination unset to send each message back to its original source, or choose a same-type custom destination. AWS can choose the rate, or you can set 1 to 500 messages per second. While a task is running, the dialog shows its progress with a Cancel control and will not let you start another, because SQS allows one active move task per source queue. Cancelling stops only the messages that have not moved yet.
AWS authorizes the work the task performs, so the identity needs sqs:StartMessageMoveTask, sqs:ReceiveMessage, sqs:DeleteMessage, and sqs:GetQueueAttributes on the source DLQ, plus sqs:SendMessage on the resolved destination queue or queues. SSE-KMS queues also need the matching KMS permissions. The dialog resolves the selected destination and shows separate access notes for starting, viewing, and cancelling a task. Those notes are a best guess.
In Free, Start queue redrive and Cancel are disabled with a Requires Tarmac Pro explanation. The progress of a running task stays readable, and losing Pro never hides it.
A typical DLQ session
- Select the DLQ and fetch with a visibility timeout sized for your review. Deleting originals needs live handles at publish time.
- Open facets on the error fields to bucket the failures.
- Work through the buckets. Inspect a few representatives from each. Fixable by a code change? Fix and Send to the chosen destination. Malformed beyond saving? Stage deletes. Wrong payload but salvageable? Edit & Send that one message.
- Open Staged, review the actions, and choose Publish Actions before the visibility window closes.
- Watch the destination queue with Live Tail to confirm redriven messages are being consumed and not boomeranging back into the DLQ.
Mind maxReceiveCount when browsing source queues
Messages move to a DLQ when their receive count exceeds the source queue's max-receive setting, and every receive counts, including Tarmac's. On a queue with a threshold of 1 to 3, browsing with repeated fetches can push messages into the DLQ by itself. Check the threshold in Topology on the "Max receives" chip, fetch once, and work from the cache.