Silent failure vs rejected webhook: two failures that need opposite monitoring
Reference definitions, with measured examples of both · updated 2026-08-13 · no affiliate links on this page
A rejected webhook fails loudly: the delivery attempt gets an error response (429, 503, a timeout) and the sender knows at delivery time. A silent failure fails politely: the platform answers "success", and the work then never happens. In 8,471 monitored runs across Zapier, Make, n8n and Pipedream we have recorded exactly one organic rejection - and, at one platform's free-tier quota wall, 14 of 14 events silently discarded behind success responses. The rejection cost us one retry. The silent drops were only visible because we reconcile every event against a ledger.
The two failure modes are routinely blended in monitoring discussions, and the blending is expensive: every mitigation that catches one is structurally blind to the other. This page defines both precisely, shows measured examples, and maps which monitoring catches which.
The definitions
Rejected webhook (rejected at send). The receiving platform refuses the delivery: the POST returns a non-2xx status or the connection fails. No run is created - the event never enters the platform, so the platform's own execution history has no record it existed. The failure is loud at exactly one place: the sender's outbound request. If the sender checks response codes, every rejection is observable and retryable. If it doesn't, a loud failure quietly becomes a silent one - downstream of the platform, in your own code.
Silent failure. The platform accepts the event and answers success; the expected output then never appears, and no error is surfaced anywhere. The sender's logs say delivered, the platform's history says nothing is wrong (often it says nothing at all), and the absence only becomes visible when someone compares what went in against what came out. We measure this as the Silent Failure Rate: (missed + partial executions) ÷ all runs expected to produce output, always with a Wilson 95% confidence interval.
Side by side
| Rejected webhook | Silent failure | |
|---|---|---|
| What the sender sees | An error, at delivery time | "Success" |
| Platform execution history | Nothing (no run was created) | Nothing wrong (or nothing at all) |
| Who can detect it | The sender, by checking response codes | Only outcome verification at the destination |
| Recovery | Retry - immediately and automatically, if built | None until a human notices the gap |
| Cost per incident | Seconds, if handled | Unbounded - runs until discovered |
| In our SFR accounting | Excluded (reported separately as rejected_at_send) | The numerator |
Both, measured
- The one rejection. On July 7, 2026 our deliberately small self-hosted n8n box (1 GB VM) briefly saturated under a 10-event burst and refused one POST. The controller saw the error at send time; n8n has no record the event existed; the events 600 ms before and after delivered normally. Full trace in the forensic section of the reliability page. It reproduced under experiment load once since - and never under normal operation in 5,989 output-expected n8n runs.
- The silent drops. When Pipedream's free-tier quota ran out mid-measurement, its webhooks kept answering success while discarding every event: 14 of 14 output-expected runs, no error, no queue, no status-page incident. The sender could not have known; our ledger reconciliation is the only reason we did. Details on the reliability page.
- The grey zone. In our 30-minute outage experiment, one platform's pending automatic retries were invisible in every UI surface while they waited - not a silent failure (delivery eventually completed, exactly once), but a reminder that "no visible record" and "failed" are different claims.
What this means for monitoring
Response-code checking at the sender and outcome verification at the destination are not redundant - they cover disjoint failure classes. The sender-side check converts every rejection into a handled event and costs almost nothing. The destination-side check (count events in, count completed outputs, compare on a schedule) is the only mechanism that catches accepted-then-vanished, because it is the only one that does not trust anything the pipeline says about itself. Run both; neither substitutes for the other.
FAQ
What is the difference between a rejected webhook and a silent failure?
Whether the sender finds out at delivery time. A rejected webhook answers with an error or nothing at all - the failure is loud, observable in the sending system's logs, and retryable. A silent failure answers with success and then the work never happens - the failure is invisible to the sender, absent from its logs, and unretryable because nobody knows to retry. The two need different monitoring: rejections are caught by checking response codes at the sender; silent failures can only be caught by verifying outcomes at the destination.
Does a 429 or 503 response mean my automation failed silently?
No - the opposite. A 429 (rate limited) or 503 (unavailable) response is a loud failure: the sender was told, at delivery time, that the event was not accepted. It only becomes a silent failure if the sending system ignores the response code and reports success anyway - which is a sender bug, not a platform behaviour. In our measurements the rejected event leaves no execution record on the platform at all, so the platform's own history cannot show you it ever existed; the sender's record is the only evidence.
Why doesn't BenchTruth count rejected webhooks in the Silent Failure Rate?
Because SFR measures a specific promise: accepted means delivered. A rejection breaks a different promise (availability), and the caller sees it break, so blending the two would hide the distinction that matters operationally. Our ledger records send outcomes separately: rejected-at-send events are excluded from SFR's numerator and denominator and reported on their own. Across our whole measurement window we have recorded exactly one organic rejection - a deliberately small self-hosted n8n VM refusing one POST during a 10-event burst - and it is documented, not blended.
Which failure should I worry about more?
Silent failures, by an order of magnitude - not because they are more common (in our data they are rarer under normal operation), but because their cost per incident is unbounded: nobody knows when they start and nothing triggers recovery. A rejection is self-announcing; with response-code checking and a retry, it usually costs seconds. The practical priority order: make the sender check response codes (converts every rejection into a handled event), then add destination-side verification - counts in versus counts out - which is the only net that catches the silent kind.
Related
The live Silent Failure Rate scoreboard · Uptime is not your failure rate · The 200 OK error · Webhook retry semantics, measured