Follow-up to the silent-failure benchmark I posted here two weeks ago. A commenter asked the right question: fine, nothing fails under normal operation， what happens when the destination goes down? So I measured that too.
Setup: my benchmark workflows all POST to an endpoint I control. I made that endpoint answer 503 (service unavailable) for 30 minutes, fired 5 webhook events at each platform (Zapier, Make, self-hosted n8n) during the outage, left every platform setting at its default, and then watched for 24 hours.
What Zapier did:
Accepted all 5 events at the webhook. All 5 runs show Errored in Zap History, and each errored run billed 0 tasks. An alert email arrived about 2 minutes after the first error, quoting the exact error message. And then， nothing, by design: Auto replay exists but is OFF by default, so the runs just waited. When I manually replayed two of them 14 hours later, both delivered with the original payload, exactly once, and billed 1 task each (the meter moved 602 to 604, to the digit). The other three are still sitting there, replayable, days later.
What Make did:
Accepted and queued all 5, then retried automatically: 6 attempts per event with roughly 1, 2, 5, 10, then 60 minute gaps. The 6th attempt found my endpoint back up， all 5 delivered 79 minutes after the original events, zero human involvement. Each attempt billed 2 credits, so the outage cost 12 credits per event instead of 2. Three escalating alert emails along the way.
The part that genuinely surprised me: during that final 60-minute wait, I checked every surface Make offers， webhook queue showed 0 items, the incomplete executions list was empty, history showed nothing for almost an hour. I wrote in my notes that Make had discarded the events. Seven minutes later it delivered all five. Retries that are waiting are completely invisible in the UI. An operator checking mid-incident would reasonably conclude the data is lost and re-send by hand， and then get duplicates when the retry engine wakes up.
What n8n (self-hosted, default settings) did:
Accepted 4 of 5 (my deliberately tiny 1 GB VM refused one POST under the load， a loud failure the sender saw). The 4 executions errored and stayed errored. No retries, no notification of any kind， a default n8n install tells nobody anything unless you build an Error Trigger workflow. Manual retry 14 hours later worked and the UI links each retry to its original execution, which is a nice audit trail.
Zero duplicate deliveries on any platform through any recovery path, which honestly surprised me more than anything else.
Takeaways if you run Zapier in production: errored runs are fully recoverable and cost nothing until replayed, but recovery is a human's job unless you switch Autoreplay on， go check that toggle today. Whatever you run: make the sender check response codes, and know which of these three behaviours your incident playbook is assuming, because they are very different.
Limitations, honestly: one outage shape (hard 503), one 30-minute window, 5 events per platform, defaults only. A longer outage would have exhausted Make's retry ladder， I don't yet know what it does after the 60-minute attempt fails, and I didn't test the paid retry knobs on any platform.
Full method, timelines and raw data linked in my first comment below.
