# Your Retry Logic Is Lying to You A webhook that returns 401, 422, 429 or 503 is not asking for the same treatment. Reliable event delivery is not about more retries. It is about better decisions. Author: Sverre Senneset — CEO, Queuey Published: 2026-07-07 Retry logic makes teams feel safe. Something failed? Try again. Still failed? Try again later. Add exponential backoff, move it to a dead-letter queue, and call it resilient. It feels responsible. But your retry logic is lying to you. Most webhook systems operate as a pure **DeliveryEngine**. They are dumb pipes. They push data, count attempts, and apply one global retry policy to every single failure. But treating every error as a timeout is not reliability. It is pretending the system knows what to do. A `503` might be temporary downtime. Retrying later makes sense. A `429` is not downtime. The receiver is telling you to slow down. A `401` is telling you authentication is broken. A `422` is a structural mismatch: the payload does not match the contract. A broken payload does not become valid through persistence. ## Retry is not recovery Blind retry looks productive. Attempts increase. Dashboards move. Logs fill up. But motion is not progress. When a **DeliveryEngine** treats all errors identically, the consequences are brutal. Why retry a `422` twelve times before discarding it? Retrying a missing field or a broken schema is not resilience. It is automation without judgment. It wastes compute, fills logs with noise, and creates head-of-line blocking for valid events. Why send a `503` to a dead-letter queue, just so the next 100 events can meet the same fate? When a receiver goes down, a dumb pipe hammers it until retries run out, sending perfectly valid data into a DLQ graveyard purely because of bad timing. You end up manually rescuing healthy events because your system could not pause. At some point, aggressive retry logic becomes operational theatre. Everyone can see that the system is trying. Nobody can see that it does not understand the failure. And then there is the part nobody likes to say out loud. ## The wrong incentive In many usage-based webhook tools, a dumb **DeliveryEngine** is good for business. More retries mean more billable volume. More attempts. More traffic. More money. But the customer does not need more noise. They need the flow restored. If a payload is invalid, sending it again and again is expensive denial. Reliable delivery is not about pushing harder. It is about knowing what to do next. ## The 422 test A `422` is one of the clearest signals a receiver can give you. The event arrived. The receiver understood the request. But the payload does not match the contract. That is not downtime. That is not a network problem exponential backoff will fix. It is a structural problem: a missing field, a renamed property, a type mismatch, or contract drift. That is the idea behind our payload-422 scenario. It shows the difference between retrying a failure and understanding it. The receiver rejects `customer.email` as missing. Queuey finds the value at `customer.contact.email` and suggests the smallest safe JSON Patch — approved by a human. ## From DeliveryEngine to DecisionEngine Webhook infrastructure does not need another **DeliveryEngine**. It needs a **DecisionEngine** — a layer that classifies the failure before deciding what to do next. A `401`, a `422`, a `429`, and a `503` are not cousins. They are fundamentally different signals that demand entirely different decisions. A `503` requires a circuit breaker to let the queue build up safely. A `429` requires a rate limiter to ease the pressure. A `422` requires an immediate halt and a structural fix. Queuey is built around this exact principle: classify the failure, reduce unnecessary retries, preserve the evidence, and help the customer actually recover. Not more attempts. Better decisions. Retry is a mechanism. Recovery is the product. Everything else is just traffic. Source: https://queuey.ai/articles/your-retry-logic-is-lying-to-you/