Auto-replay Amazon SQS dead-letter queues after a GitHub merge

PromptCreate

When a pull request is merged in GitHub, decide whether that merge is a bug fix worth replaying failed messages for, and if so redrive the matching Amazon SQS dead-letter queue automatically. Use a webhook trigger on merged pull requests.

Start by calling the GitHub Get a Pull Request action for the merged pull request and read its title, body, and labels. Only proceed when the pull request carries a redrive label (for example redrive or replay-dlq) or names a queue in its description on a line like "Redrive: orders-processing-dlq". If neither signal is present, stop silently: do not comment, do not post to Slack, and do not touch any queue.

When it does proceed, use the Amazon SQS Get Queue URL action to resolve the named dead-letter queue by name. Then call Get Queue Attributes to read the approximate number of messages, and stop if the queue is already empty. Call List Dead Letter Source Queues against that queue to confirm it really feeds the source queue the fix targets, and use the source queue it returns as the replay destination. Only SQS dead-letter queues can be used as a redrive source, so if the named queue turns out not to be a dead-letter queue for any source queue, stop and say so in Slack instead of starting a task.

Sample a handful of messages (up to 10) with the Receive Message action so you can summarise what was actually failing before touching anything. Read them only. Never call Delete Message, Delete Message Batch, or Purge Queue on the sampled messages, so the visibility timeout returns them to the queue and the replay stays complete.

Before starting any replay, apply two safety gates. Do not redrive when the dead-letter queue depth is above a configurable ceiling, defaulting to 5,000 messages. Do not redrive when the pull request is a revert, which you can detect from a title starting with "Revert" or a revert label. In either case, skip Start Message Move Task entirely and instead post the summary to Slack asking a person to confirm before the replay runs.

When both gates pass, call Start Message Move Task with the dead-letter queue as the source and the confirmed source queue as the destination, throttled with a messages-per-second cap (default 10) so the replay does not overwhelm the consumer. Start Message Move Task is asynchronous: it returns a TaskHandle rather than finishing inline. Follow up with List Message Move Tasks to read the current status and how many messages have moved so far.

Finally, post the replay receipt back on the merged pull request with the GitHub Create an Issue Comment action, and send the same summary to the engineering channel with the Slack Bot Send a Message action. Both should cover which queue was replayed, how many messages were in it, a plain-English read on the failure pattern from the sampled messages, and the move task status. Report the status you actually observed rather than claiming the replay has completed, since the task keeps running in the background after the workflow finishes.

Example output

Replayed orders-processing-dlq after PR #482 (Fix null customer ID in order consumer). Messages in the dead-letter queue: 1,284 Sampled: 10 messages What was failing: every sampled message failed on a missing customer ID field, which is the exact case this merge fixes. All samples came from the checkout service between 02:10 and 06:45 UTC. Replay: running, moving messages back onto orders-processing at 10 per second. 340 of 1,284 moved so far.

What does this prompt do?

Watches for merged pull requests and only acts when the pull request is tagged for a replay or names a queue to replay, so ordinary merges are ignored.
Checks the dead-letter queue before touching it: confirms it is not empty, confirms it really feeds the queue your fix targets, and samples a few stuck messages to work out what was failing.
Replays the backlog onto the live queue at a steady, capped rate so your consumers are not flooded.
Posts a receipt on the merged pull request and in your engineering channel covering the queue, the number of messages, the failure pattern in plain English, and how the replay is progressing.

What do I need to use this?

An AWS account with Amazon SQS queues, including a dead-letter queue attached to the queue you want to replay.
A GitHub repository where your team merges fixes.
A Slack workspace with a channel for engineering updates.
A shared convention for marking a pull request as replay worthy, either a label or a line in the description naming the queue.

How can I customize it?

Change the label or the description keyword that marks a pull request as worth replaying.
Raise or lower the safety ceiling on queue size, 5,000 messages by default, above which the agent asks a human before replaying.
Adjust how fast messages are replayed and pick which Slack channel gets the summary.

FAQs

Will this replay messages every time we merge something?

No. It only acts when a pull request is explicitly marked, either with a replay label or a line in the description naming the queue. Every other merge is ignored and nothing gets posted.

Does it delete the failed messages while it inspects them?

No. It reads a small sample to work out what went wrong and leaves every message in place, so nothing is lost and the replay stays complete.

What happens if the queue has a huge backlog?

There is a safety ceiling, 5,000 messages by default. Above that the agent stops and asks in Slack for a person to confirm rather than replaying on its own.

What if the merge was a revert rather than a fix?

Reverts are treated as unsafe to replay automatically. The agent skips the replay and posts a summary asking someone to confirm first.

Will it tell me when the replay has finished?

It reports the status of the replay at the moment it posts. Replays keep running in the background, so the summary tells you how far along it is rather than claiming it is already done.

Related templates

Build a credential rotation checklist when someone leaves

When someone leaves, we check which shared passwords they used in their final months and post a ranked rotation list to your security channel.

+1

Agentic Task

Weekly Amazon S3 bucket security audit posted to Slack

Every Monday, check every S3 bucket for public exposure, missing encryption and weak backup settings, then get the risks ranked in Slack.

Agentic Task

Log Agorapulse social conversations to HubSpot contacts

Twice every weekday, the conversations from your social inbox land on the right HubSpot contact timelines, with a Slack recap for sales.

Agentic Task

Clean up HubSpot contacts from your Amazon SES suppression list

Every morning, find the addresses that hard bounced or filed a spam complaint, update the matching HubSpot contacts, and post a short Slack recap.

Agentic Task

Draft polite follow-ups for emails that never got a reply

Every weekday at 4pm, spot the threads that went quiet, stage a ready-to-send nudge in your mailbox, and get a ranked Slack recap.

Agentic Task

Provision customer entitlements in DynamoDB when a deal is won

When a HubSpot deal hits Closed Won, the customer's plan, seats and renewal dates land in your DynamoDB accounts table, with a Slack note showing what changed.