Uptime is not your failure rate
What status pages measure, what they structurally miss, and what to measure instead · updated 2026-08-13 · no affiliate links on this page
A platform can report 99.99% uptime while your workflow loses 100% of its events. We measured exactly that: at a free-tier quota wall, webhooks kept answering success while 14 of 14 deliveries vanished - and no incident ever appeared on a status page, because nothing the status page measures had failed. Uptime answers "did the service respond". Your failure rate answers "did my run complete, correctly, on time". They are different quantities, measured at different layers, and they diverge precisely where failures get expensive.
When buyers ask which automation platform fails least, the answers they get are increasingly built from uptime SLAs and status-page statistics - numbers that are real, audited, and answering a different question. This page is the reference for the distinction, with the measured cases where the two metrics came apart.
What each layer can see
| Failure mode | Visible to uptime / status page? | Visible to per-run reconciliation? |
|---|---|---|
| Platform-wide outage | Yes (its home turf) | Yes (as a burst of failures) |
| Quota wall silently discarding events | No - service is up, requests answered | Yes (14/14 caught in our data) |
| Partial execution (1 of 2 branches ran) | No | Yes (expected 2, got 1) |
| Trigger quietly stopped firing | No - no error exists anywhere | Yes (events in ≠ runs out) |
| Late delivery (arrived, an hour behind) | No - it completed | Yes (latency percentiles) |
| Transport success, wrong result (200 OK, bad write) | No | Partially (needs read-after-write checks - see the 200 OK error) |
The pattern: uptime sees exactly one row of this table. Every other row logs as normal at the platform layer and is only visible by comparing intent against outcome - which is what our per-run reconciliation does, 8,471 monitored runs and counting.
Why the substitution keeps happening
Uptime is published, audited and contractual; per-run failure rates are almost never published by anyone. So when a comparison needs a reliability number, uptime gets substituted - not because anyone believes 99.9% uptime means 99.9% of runs succeed, but because it is the number that exists. The result is reliability rankings built from SLA marketing, status-page incident counts, and review-site stars, none of which measured a single workflow run. Our benchmark exists to publish the number that was missing: the per-run rate, with its sample size and confidence interval attached, from a harness where both endpoints are controlled and every event is reconciled.
The measured divergences
- Quota wall, 2026-07-02. Pipedream's free-tier credits ran out mid-measurement. Platform up, webhooks answering success, 14 of 14 output-expected events silently discarded, re-verified 19 hours later. Uptime for the window: 100%. Our measured delivery rate: 0%.
- Our own outage experiment, 2026-08-01. We took our receiving endpoint down for 30 minutes. Every platform's uptime was untouched - the failures were entirely per-run (errored, queued, retried, or waiting for a human), with three platforms behaving three different ways. None of that is a status-page event. Full results: webhook retry semantics.
- The one rejection. A saturated 1 GB self-hosted VM refused one POST out of a burst - an availability blip at the run level that no uptime metric would register, documented in rejected vs silent.
FAQ
Is uptime the same as reliability for automation platforms?
No. Uptime answers 'did the service respond' at the platform level; reliability for an automation user is 'did my run complete, correctly, on time' at the run level. The gap between the two is where the expensive failures live: a platform can be fully up while a quota wall silently discards your events, while a run half-completes, or while a delivery lands an hour late - all of which log as normal from the platform's side. In our measurement, the only way to see run-level reliability was to reconcile every fired event against every received output; no status page participates in that arithmetic.
Why does my automation fail when the platform status page is green?
Because the status page reports acknowledged platform-level incidents, and most run-level failures are neither platform-level nor acknowledged. The usual suspects: an expired credential (your run fails, the platform is fine), a filter that started eating everything after a field rename, a quota boundary (we measured webhooks answering success while dropping 14 of 14 events - no incident was ever posted), a trigger that quietly deinitialized, or a third-party API rejecting your payloads with the platform dutifully recording 'success' for the transport. Green status and a broken workflow coexist comfortably; only outcome-level checks notice.
What should I measure instead of uptime?
Three run-level numbers, all computable from your own data: completion (events in versus expected outputs out, reconciled on a schedule - catches silent drops and absent runs), correctness (spot-check that what was written matches what was sent - catches 200-OK-with-wrong-data), and timeliness (delivery lag percentiles - catches the run that arrived an hour late and logged the same green as an on-time one). Uptime remains worth watching as a leading indicator; it is just not the metric your business depends on.
Related
The live Silent Failure Rate scoreboard · Silent failure vs rejected webhook · The 200 OK error · Webhook retry semantics, measured