Webhook Failure Monitoring for Zapier, Make and n8n: Why We Didn't Build the Retry Dashboard

The oddly specific problem

Three major automation platforms, one deliberately broken endpoint, and three very different definitions of "we've got this."

Webhook failure monitoring across Zapier, Make and n8n sounds like a solved problem until someone actually tests it. Someone ran a deliberately cruel experiment: they took a webhook endpoint offline for thirty minutes and watched what three major automation platforms did about it.

Make.com behaved well, sort of. It retried each failed event six times with widening gaps (roughly one, two, five, ten, then sixty minutes). But during that final sixty-minute wait, the retries were invisible. The webhook queue reported zero items. Incomplete executions: empty. History: nothing. If you had wandered in mid-incident, you would reasonably conclude the data was gone and start re-sending payloads by hand, which is how you turn one outage into a duplicate-records cleanup project. Make also charges two credits per retry attempt, so a single event that normally costs two credits cost twelve.

6x credit multiplier, arriving precisely when you are already having a bad day.

Zapier didn't lose the data either. Errored runs sat patiently, fully recoverable, costing zero tasks, waiting for a human to click replay. Auto Replay exists. It is off by default.

Self-hosted n8n, on default settings, did nothing. No retries, no notifications, no email. Nobody is told anything unless you have manually built an Error Trigger workflow.

The worst moments are when a Zap fails quietly and the client notices first.

Wait, is a silent Zap failure actually a problem worth paying for?

Yes, but let's be careful about how big.

The failure modes are genuinely distinct, and practitioners in these threads name three: an execution that errors, an execution that runs green but produces a broken payload, and an execution that simply never happens because the trigger stopped arriving. Native tooling reliably surfaces only the first one. The third is the nastiest, because absence of an error looks exactly like success.

Zapier's error visibility is also plan-gated. Free retains 7 days of log history; Professional at $29.99/mo (as of research) gets 30+ days and error paths, which is what you need to route custom Slack alerts. And a monitoring Zap that fires on errors consumes tasks from your own quota. You are paying to be told your automations broke.

The most common workaround is a free master Zap using the Zapier Manager trigger to catch errors across folders and ping Slack. It only works inside one account, so it fails the agency multi-client case entirely. But it costs nothing, and it already exists in a lot of accounts.

Who's already solving webhook failure monitoring

Nine tools cover some slice of this, from purpose-built Zapier error monitoring to general-purpose uptime dashboards. Prices are as of research.

So why isn't the retry dashboard a slam dunk?

We wanted to build the unified retry dashboard. Then we looked at four things and stopped.

The market has an occupant and a landlord. NotiLens is already live, charging money, and covering the same three platforms with the same feature list. Our first instinct was to read that as demand validation. It reads better as a first mover with the exact product and the exact buyer. Hookdeck, which we initially missed entirely, has the funded, production-grade version of the proxy-relay-retry architecture we sketched. Discovering that mid-research was a useful humility exercise: if the "gap" is invisible to you until competitor number two shows up, it may not be a gap.

The architecture we called a moat is a liability. A proxy that sits in front of client webhooks means that when our proxy has its first outage, we break the automations we were hired to protect. That is not an edge case; it is the design. Fail-open mitigates it and adds complexity. Polling platform APIs avoids it and reintroduces exactly the third-party dependency the proxy was meant to escape. Also, onboarding requires the freelancer to persuade twenty clients to change a live webhook URL and re-test production workflows. Clients who did not ask for this will refuse or stall, and the product is partially useless until they don't.

The economics were reverse-engineered. Assume 1,500 signups, assume 4% conversion, arrive at ~255 paying users and a pleasant $95K ARR. No CAC, no channel, no funnel data. Realistic SEO-driven CAC for this buyer looks like $50 to $150, competing for "Zapier webhook monitoring" against Zapier's own docs plus five better-ranked incumbents. At $19/mo with plausible 3 to 6 month churn, LTV lands at $57 to $114.

That is CAC at or above LTV, which is not a business.

And the 98% gross margin claim is a software number pasted onto an infrastructure product: every delivery is inbound HTTP, a Postgres write, an S3 write, an outbound call, and an update. The highest-paying agency tier is also the highest-cost tier.

Retention is episodic by design. When monitoring works, nothing happens. A freelancer with six automations may get one alert a quarter and then quietly wonder what they're paying for. Cronitor and Healthchecks survive this because developers have dozens of jobs and a habit. Our buyer has a free Slack Zap and a 3-endpoint free tier that serves them indefinitely.

What we're watching

Four things would change our mind.

Evidence that NotiLens customers are churning for reasons other than price, which would mean the buyer wants this and isn't being served. Evidence that Hookdeck is structurally uninterested in no-code builders (its positioning skews developer, but "skews" is not "abandons"). A distribution channel with a verified CAC under $100: a Zapier app directory listing, a Make marketplace integration, or a no-code community partnership with actual referral numbers rather than vibes. And a non-proxy architecture, most likely OAuth-based polling of platform APIs, that removes the single-point-of-failure objection agencies will raise in the first sales call.

The signal we'd watch most closely is the one we can't influence: whether Zapier flips Auto Replay on by default and ships a health dashboard. If that happens, this page becomes a historical document. If it somehow doesn't happen by 2027, someone should ask why.