SQS dead letter queues
AvailableBrowse, replay, edit, and purge messages. FIFO support. Auto-replay rules. Audit log. Threshold alerts.
About
Built because every team keeps writing the same scripts.
Every team that runs services on AWS eventually accumulates dead letter queues. Some are wired into Lambda failures. Some catch SNS deliveries that never made it. Some are the polling consumer's last line of defence. And every team writes the same one-off scripts to triage them - until the page goes off again, and you're staring at a Python file you wrote a year ago at 2am.
Deadlift is the proper tooling, packaged so you don't have to build it.
- Today
- SQS DLQs
- Deployment
- CloudFormation
- Data egress
- Zero
- Pricing tiers
- 4
The problem
DLQs only matter when something is on fire.
Which means tooling for them is permanently underinvested. Engineers don't want to spend a sprint on a CRUD-ish UI that only gets used during incidents. So they don't.
And then the pager goes off and someone is SSHing through aws sqs receive-message, escaping JSON in their head, and praying their replay script doesn't double-charge a customer.
# 2:47 AM, on call
$ aws sqs receive-message \
--queue-url $DLQ \
--max-number-of-messages 10
"Body": "{\"orderId\":..."
"ReceiptHandle": "AQEB..."
# now what?
# where's the replay script?
# what does this customer get charged?
$ aws sqs send-message ...
ClientError: InvalidMessageContents
Our approach
Ship the tool. Don't ship a database.
-
The tool, not a database
Deadlift is a CloudFormation template. The dashboard, AppSync API, Lambda functions, DynamoDB tables, and Cognito User Pool all deploy into your own AWS account. We don't store, see, or process your data on infrastructure we control.
-
Hard for us, easy for procurement
Running everything in the customer's account is harder for us - we package updates, you control upgrade cadence, multi-tenancy is user-pool-based instead of database-based. But it removes the entire data-residency conversation from the sales cycle, and that's worth more than the engineering ergonomics on our side.
Who it's for
Engineering teams that take incidents seriously.
Production AWS workloads
Teams running services that handle real customer traffic. The kind who care about MTTR more than they care about feature velocity on their internal tooling.
5-50 DLQs
The sweet spot where the AWS console is too coarse and a homegrown tool isn't worth maintaining. Not just one queue, not yet a fleet - the messy middle.
Regulated environments
Healthcare, fintech, anything with a security questionnaire. The data-stays-in-your-account model removes whole sections of the review process.
Where it's going
DLQs first. Then every failure surface in AWS.
The mental model is always the same: browse the failures, replay the ones you can fix, purge the rest, audit who did what. Today that's SQS dead letter queues. Next, the rest of AWS.
-
-
Failure context
NextEach DLQ message correlated with the source-queue exception from CloudWatch Logs - so you know why it failed before you replay.
-
SNS dead letters
PlannedSNS subscription failures land in DLQs too. Same browse, replay, and audit UX, different source.
-
EventBridge failures
PlannedFailed invocations and dead letter targets, surfaced with the same triage workflow.
-
Step Functions
PlannedFailed executions surfaced with input snapshots. Replay from any state, not just the start.
-
Multi-account view
PlannedOne dashboard across every account in your org. Triage at platform-team scale.
Want to be early?
Deadlift is awaiting AWS Marketplace approval. Join the waitlist and we'll send a single email when the listing goes live - no drip campaigns, no spam.