SQS RedrivePolicy checker.
Paste a queue's RedrivePolicy JSON or the full
get-queue-attributes
output. We validate it, explain every field in plain English, and flag
the misconfigurations that bite during incidents. Entirely client-side -
your JSON never leaves the browser.
Findings show up here.
Paste a RedrivePolicy or GetQueueAttributes output on the left, or load an example. Nothing leaves your browser.
Why maxReceiveCount of 3-5 is the sweet spot.
Too low (1): retries are effectively disabled. The first timeout, cold start, or brief downstream outage moves the message straight to the DLQ. You end up manually replaying messages that would have succeeded on their own a second later.
Too high (over 10): a genuinely poison message loops through your consumer that many times before it surfaces. With a 30-second visibility timeout and a maxReceiveCount of 100, a broken message can churn for the best part of an hour - burning compute and hiding the failure - before anyone can see it.
3-5: transient failures get a real chance to succeed on retry, while persistent failures reach the DLQ within a few visibility-timeout cycles. Tune within that range based on your consumer: fewer retries when processing is expensive, more when the downstream is known to be flaky.
Deadlift manages the other end of this policy - browse, edit, and replay the messages that land in your DLQ.