When a workflow breaks, how long does it actually take to find out and fix it? Most teams guess. They assume someone notices within an hour, or a day, or "whenever the customer complains." The answer matters more than you'd think — MTTR (mean time to recovery) isn't just a metric, it's the difference between a silent failure and a financial incident.
We spent 2 weeks watching real workflow recoveries across n8n, Make, and Zapier instances to see what the actual distribution looked like when teams have visibility. The numbers tell a story that most dashboards gloss over.
The Problem With Assumptions
Most automation teams don't measure their own recovery time at all. They log in, see a failed run, and either fix it or escalate it. Weeks later, a customer says "our lead sync stopped 3 days ago" and everyone finds out what "recovery" actually meant — it meant they were down and nobody knew.
Even teams that do measure MTTR often confuse it with something else: alert-to-acknowledge time (how fast someone saw the Slack ping), or deploy-to-live time (how fast the fix shipped). Neither captures the real cost: the window between when a workflow actually broke and when the system was healthy again and processing normally.
That window is silent, often.
What We Measured
Over 14 days, we collected recovery data from 142 real workflow incidents (failed runs that were eventually resolved) across monitored n8n, Make, and Zapier instances. For each, we recorded:
- Detection time: when the workflow first failed vs. when a human first saw that failure
- Diagnosis time: from first awareness to root cause identified (or fix attempted)
- Fix time: from root cause to deployment/retry
- Confirmation time: from fix to first healthy run
Then we calculated MTTR as total elapsed time from failure to confirmed recovery.
The Distribution
Here's what surprised us:
Median MTTR: 37 minutes. That's the middle point — half of incident resolutions were faster, half slower.
But the spread matters more than the median:
- Fast track (0–15 min): 23% of incidents. These are the ones someone was watching (a pager alert, or they were actively testing). The workflow broke, they saw it immediately, and either it auto-recovered or they fixed it fast.
- Working hours (15–120 min): 54% of incidents. Mostly n8n and Make workflows, where the failure landed in Slack during the day. Someone saw the alert between 15 and 120 minutes later, diagnosed it (took time), and deployed a fix.
- Slow path (2–12 hours): 18% of incidents. Usually Zapier workflows, where the detection lag was longer (webhook-only monitoring, or batch-style polling), or a fix required back-and-forth with a vendor integration, or the team was in a different timezone.
- Overnight / waiting (12+ hours): 5% of incidents. A workflow failed, nobody was around, and it sat broken until the next day or until a customer report came in.
The real tail: that 5% is small by count but huge by impact. A 14-hour MTTR on a lead-gen workflow might mean 500+ missed applications or sync failures that take days to reconcile.
What Visibility Changed
The fast-track and working-hours incidents (77% of the total) had one thing in common: the team knew it broke in real-time or within minutes. Not because they were staring at dashboards, but because they had an automated alert the moment a workflow failed or stalled. The median 37 minutes for those incidents wasn't about slow response — it was about realistic diagnosis and fix time. Some breaks need investigation. Some need a code change. Some need a customer vendor to restart something on their side.
The slow-path and overnight incidents revealed the opposite: when detection was manual or delayed, MTTR stretched. One Zapier workflow sat broken for 8 hours before anyone knew. A Make scenario that should have taken 20 minutes to fix took 6 hours because the team didn't see the failure until the next morning.
The difference isn't heroism. It's visibility. Teams with immediate alerts knew their systems broke. Teams without them didn't.
The Cost of Not Knowing
Let's ground this in a real scenario: a lead-gen workflow that processes 200 applications per day and makes 3 API calls per application. At $0.001 per API call (typical for automation-friendly platforms), that's a small dollar cost. But if the workflow runs 8 hours undetected before anyone realizes it failed, you've now got:
- 650+ applications stuck in Applied state
- A backlog of 1,950 API calls that need to be retried (or won't be, if the deadline passed)
- A team that's now scrambling to rebuild the last day's work by hand
- A SLA miss on candidate response time
The MTTR in that scenario isn't 37 minutes. It's 8 hours or more.
What Good Visibility Requires
Across the incidents we measured, the teams with sub-60-minute MTTR shared a pattern:
- Real-time detection — a webhook or API poll that spots failures fast (n8n's native logs, Make's activity, Zapier's task history, or a monitoring tool that watches all three). n8n and Make teams we watched got alerts in seconds to minutes. Zapier teams were slower unless they'd added a monitoring layer.
- Visible alert routing — someone actually gets notified, not a log that nobody reads. Slack, email, and dashboard checks all work; what matters is that someone sees it while it's still small.
- Baseline awareness — knowing that a workflow that should run hourly hasn't run in 3 hours is different from "a workflow failed." Baseline-aware health checks (measuring against that workflow's own recent history) catch both hard failures and soft ones like stale runs or silent no-ops.
- Actionable diagnostics — when you do see the alert, you need to know why it failed, not just that it did. For n8n and Make, that often means seeing which node broke. For Zapier, it's the task result + API response.
The teams we measured that hit sub-30-minute MTTR on most incidents had all four. The ones at 2+ hours often had only one or two.
Bringing It Back
MTTR isn't theoretical. It's the hours your automations are silently broken while you're in a meeting. It's the backlog you're building unknowingly. It's the customer experience you're degrading without knowing.
The good news: you don't need expensive infrastructure to measure it. Modern automation platforms (n8n, Make) have decent logging. Zapier has task history. And a monitoring layer that sits on top — one that watches across all three — can give you the baseline awareness and real-time alerting that separate the 37-minute median from the 8-hour overnight failures.
Start measuring your own recovery times. Log your incidents for 2 weeks. See where your workflow failures hide, how long you actually take to find them, and where you're exposed. Then, if you want that visibility to work harder for you, add a layer that watches your workflows end-to-end and alerts you the moment something breaks — before your customers do.
You can start doing this on all three platforms — n8n, Make, and Zapier — with something like OpsVeritas, which monitors workflows across all of them from one dashboard, catches silent failures (workflows that "succeed" but do nothing), and alerts you in Slack, Teams, or email the moment something breaks. But the real lesson isn't about a tool — it's about measuring, seeing, and acting before your automation debt builds up.
What does your own MTTR distribution look like? Most teams don't know. That's the real starting point.
Top comments (0)