Webhook retry semantics, measured: we took our endpoint down for 30 minutes on Zapier, Make and n8n
Controlled outage experiment, August 2026 · all platform settings at their defaults · updated 2026-08-04 · no affiliate links on this page
When the destination of a webhook goes down for 30 minutes, only one of the three major automation platforms recovers on its own: Make retried each event 6 times over 79 minutes and delivered everything - billing 2 credits per attempt, with the pending retries invisible in every corner of its UI. Zapier and self-hosted n8n retried nothing (their retry features ship switched off), but preserved every failed run for manual replay, which delivered the original payloads exactly once even 14 hours later. No platform produced a duplicate.
"Does it retry?" is the question that decides whether a five-minute outage becomes a data-loss incident, and vendor docs answer it in feature lists rather than behaviour. So we measured the behaviour: our benchmark workflows all POST to an endpoint we control; we made that endpoint answer 503 for a 30-minute window, fired 5 tagged events at each platform during the outage, changed no default settings, and watched for 24 hours. These runs are excluded from our silent-failure scoreboard - stress experiments never share a denominator with normal operation.
The scoreboard
| Zapier | Make | n8n (self-hosted) | |
|---|---|---|---|
| Accepted during outage | 5 / 5 | 5 / 5, queued | 4 / 5 * |
| Automatic retries | None (off by default) | 6 attempts | None (off by default) |
| Retry spacing | n/a | ≈ 1, 2, 5, 10, 60 min | n/a |
| Full recovery | Manual, +14 h | Automatic, +79 min | Manual, +14 h |
| Outage cost | $0 ** | 12 credits/event (6× normal) | $0 |
| Who told you | 1 email, ~2 min | 3 escalating emails | Nobody |
| Duplicates | 0 | 0 | 0 |
* The fifth POST was refused at n8n's webhook by our deliberately small 1 GB VM - a loud failure the sender saw immediately, not a silent one. ** Errored Zapier runs billed 0 tasks; a manual replay bills 1 task like a normal run (meter-verified: 602 → 604 for two replays). Retry features that exist but ship disabled: Zapier Autoreplay, n8n per-node Retry on Fail.
The finding that matters most: Make's retries are invisible while they wait
During the 60-minute gap before Make's final attempt, we checked every surface it offers: the webhook queue showed 0 items, the incomplete-executions list (the URL calls it dlq) was empty, and the scenario history showed no activity for nearly an hour. Every indicator agreed the events were gone - we wrote them off in our own notes. Seven minutes later, Make delivered all five.
The retries work. You just cannot see them pending. An operator checking mid-incident sees "queue empty, no dead letters, nothing scheduled" and reasonably concludes the data is lost - then re-sends by hand, and collects duplicates when the retry engine wakes up behind them. If you run Make in production, write this down somewhere your future 2am self will find it: after an outage, wait out the backoff ladder (attempts at roughly +1, +2, +5, +10, then +60 minutes) before re-sending anything.
What this means for your incident playbook
- On Zapier: check the Autoreplay toggle today - it is off by default, and with it off, every outage needs a human to notice the alert email and replay the errored runs. The runs wait patiently and replay cleanly, but they wait for you.
- On Make: your automation self-heals from outages shorter than its backoff ladder (~80 minutes of coverage in our measurement) - budget the retry credits, and never re-send manually during the invisible waiting period.
- On self-hosted n8n: build the Error Trigger workflow before you need it. A default install fails in complete silence - the failure is visible in the executions list, but only if you go look.
- Everywhere: make the sender check response codes (a refused POST is recoverable only if somebody noticed it), stamp events with unique IDs, and keep writes idempotent - that combination is what made "exactly once" hold on every recovery path we tested.
Method and limits
- Identical webhook→HTTP workflows on every platform, both endpoints ours; the receiver answered 503 only to experiment-tagged events, so baseline traffic was untouched. 5 events per platform, fired during a 30-minute window; 24-hour observation; every delivery reconciled by run ID against a ledger written before firing.
- Honest limits: one outage shape (hard 503), one window length, small n, defaults only. A longer outage would exhaust Make's ladder - what happens after the +60-minute attempt fails is not yet measured. Paid retry knobs (Zapier Autoreplay on, n8n Retry on Fail, Make's incomplete-executions storage) are a follow-up experiment.
- Full timelines, screenshots-backed narrative and the live scoreboard live on the reliability page; raw per-run data is downloadable there (CC BY 4.0).
FAQ
Does Zapier retry failed webhook deliveries?
Not by default. In our measured 30-minute outage (August 2026), all 5 events were accepted, errored when the destination answered 503, and then simply waited: Zapier's Autoreplay feature exists on paid plans but ships switched off. The good news: errored runs billed 0 tasks, an alert email arrived about 2 minutes after the first error quoting the exact error message, and the failed runs stayed replayable indefinitely - our manual replay 14 hours later delivered the original payloads exactly once and billed 1 task each (the task meter moved 602 to 604, to the digit).
Does Make retry failed scenario executions?
Yes - and it was the only platform in our test that did. Make queued all 5 events and retried each 6 times with roughly 1, 2, 5, 10, then 60-minute gaps; the 6th attempt found our endpoint back up and all 5 delivered 79 minutes after the original events with no human involvement. Two costs to know about: every attempt billed 2 credits (so the outage cost 12 credits per event instead of 2), and pending retries are invisible - during the 60-minute wait the webhook queue showed 0 items, the incomplete-executions list was empty, and history showed nothing. We wrongly concluded the events were lost; seven minutes later they all arrived.
Does n8n retry failed workflow executions?
Not by default. n8n has a per-node Retry on Fail setting, but it ships off; a default self-hosted install also sends no notification of any kind when an execution errors - nobody emails you unless you build an Error Trigger workflow. The errored executions are preserved, and manual retry (ours ran 14 hours later) works cleanly, with the UI linking each retry to its original execution. On our deliberately small 1 GB VM, 1 of 5 events was also refused at the webhook itself under load - a loud failure the sender saw immediately.
Do retried webhook deliveries create duplicates?
In our test: never. Across Make's 6 automatic attempts per event, Zapier's manual replays, and n8n's manual retries, every accepted event was delivered exactly once - zero duplicates on any platform through any recovery path. The bigger duplicate risk we identified is human: because Make's pending retries are invisible in its UI, an operator checking mid-incident could reasonably conclude the data is lost, re-send by hand, and collect duplicates when the retry engine wakes up. If your sender stamps every event with a unique ID and your writes are idempotent, both the platform paths and the human path become safe.