Your automation says it worked and nothing happened. Here is what we measured.

There are plenty of articles listing why automations fail. This one lists only causes we have actually observed and measured, in the order worth checking. The short version: the platform engines are rarely the culprit - zero silent drops in 10,777 monitored runs across Zapier, Make, self-hosted n8n and Pabbly - while filters, response bodies, quota edges and runs that never started account for nearly everything people experience as "it said success and did nothing".

We run identical workflows on these platforms around the clock with both endpoints under our own control, and reconcile every fired event against every received result. That gives us something a troubleshooting guide usually can't offer: numbers under each claim, and honest confidence intervals around them.

Check these in this order

1. A filter stopped the run, and that looks like success

The most common cause, and the most misleading, because nothing is wrong from the platform's point of view. On Zapier a run halted by a Filter is recorded as Filtered or Safely Halted - a neutral status, not an error - so no error notification is ever sent. We measured the billing side of this too: filtered runs consume 0 tasks, and the Filter step itself is free. Nothing bills, nothing alerts, nothing happened.

What to check: open the run and look at the status; if it says Filtered, read the filter's condition against the actual field values in that run. The usual trigger for a sudden wave of them is a renamed or restructured field upstream, after which the condition silently matches nothing.

2. The API answered 200 OK with an error inside the body

A destination returns HTTP 200 - the transport worked - and puts the failure in the response body ({"ok": false, "error": …}). We tested this deliberately: we made our own endpoint answer real 200s carrying an error body and sent them through Zapier and self-hosted n8n at default settings. Both recorded 3 of 3 as fully successful; Zapier billed each one 1 task, exactly like a success; n8n counted them toward its dashboard's 0% failure rate. The error text was captured and visible in the step output the whole time. The blind spot is not that platforms can't see it - it's that success is decided on the status code before anything reads the body.

What to check: open the last action's output data and read the body, not the status. To catch it automatically, add one response assertion (a Filter on the response's success field). We measured that cost too: $0 standing - the assertion only bills a step on the runs where it actually catches something. Full experiment: the 200 OK error.

3. The run never started, so there is nothing to find

A trigger stopped firing, a credential expired, a webhook subscription was dropped on reauth, or the workflow sat deactivated after an edit. This is the failure that costs the most, because a run history cannot show you a run it never created - from inside the platform, "no runs" and "a quiet week" look identical.

We hit this in our own harness, twice, and both are documented rather than hidden: a Make scenario that stayed switched off after an edit (events queued silently for nine hours), and our own Pabbly throttle that depended on a fixed clock hour and stopped firing for three days when the scheduler drifted. Neither produced a single error anywhere.

What to check: compare counts at the source against counts at the destination for the period in question. Then make it automatic - see the last section.

4. It arrived, just far too late

Success semantics ignore time. In our outage experiment, one platform's automatic retries delivered everything successfully 79 minutes after the original event - logged exactly like a delivery that took one second. If the downstream cares about freshness or ordering, that green checkmark is lying by omission. Worse, while those retries were pending they were invisible in every UI surface the platform offers, so an operator checking mid-incident would reasonably conclude the data was lost. Full measurements: webhook retry semantics.

What to check: compare the delivery timestamp with the source event's timestamp, not just whether a row exists.

5. A quota edge accepted your events and discarded them

The one case where the platform really did drop accepted work silently, and we caught it live: when a free-tier quota ran out mid-measurement, that platform's webhooks kept returning success while discarding 14 of 14 deliveries. No error, no queue, no status-page incident, nothing for the sender to see. If an automation touches revenue, don't run it at the edge of a free tier.

6. Only then: the platform silently dropped it

Last, because it is the rarest. Across 10,777 monitored runs we have observed zero silent drops under normal operation on any platform we test. The honest way to state it is with sample sizes attached, since zero in 27 runs and zero in 7,663 runs are very different claims:

Live numbers, method and the raw per-run CSV: the reliability scoreboard. One related case that is not a silent failure: a webhook refused at the door (a 429 or a saturated server) is a loud failure the sender can see and retry - we have recorded 2 of those in 7,663 n8n runs. The distinction matters: silent failure vs rejected webhook.

How to stop finding out from your client

Everything above is diagnosis after the fact. Two mechanisms catch these prospectively, and they cover different classes:

• Daily count reconciliation. Count what entered the source and what landed at the destination; compare on a schedule; alert on the gap. This is the only check that catches runs which never started, because it does not depend on the pipeline reporting anything. It also catches partial failures - the 9-of-10 case that per-run monitoring never sees.
• A synthetic canary. Fire one test event through the real path on a known cadence and verify it arrives. This converts "absence" into a scheduled expectation that either happened or didn't. Our entire benchmark is a canary running continuously - that is how we can state a rate at all.
• Stamp an ID on everything. Generate an ID at the trigger, write it onto whatever the workflow touches. "Did event X actually land, with the right values?" becomes a query instead of archaeology, and it makes retries safe to repeat.
• Rehearse it once. Turn a test workflow off on purpose and confirm the alert reaches a human. A monitor you have never seen fire is a hope, not a monitor. Ours only proved itself when a real miss finally appeared and the forensics matched.

Whichever platform you run, the ordering above holds: check the filter, read the response body, ask whether the run existed at all, and only then suspect the engine. That order comes from the measurements, not from intuition - and the measurements are published, with their sample sizes, for anyone to check.

FAQ

Related measurements

Live silent-failure scoreboard · The 200 OK error, measured · What platforms do during an outage · Silent failure vs rejected webhook · Uptime is not your failure rate