Your Average MTTR Is a Fiction
TL;DR: Relying on a single mean-based MTTR is mathematically flawed because incident data follows a power-law distribution, not a bell curve. Recent data from 1.8 million outages reveals a 10x gap—a 1.9-minute median vs. 21.9-minute mean—meaning a single average misrepresents the true customer experience and hides the catastrophic tail incidents.
Engineering leaders have long suspected that Mean Time to Resolve (MTTR) is a vanity metric. It is often the first number shared in quarterly business reviews, yet it feels disconnected from the lived reality of an on-call engineer. The reason is a fundamental statistical mismatch: we apply linear averages to non-linear, high-variance events.
When you report a single MTTR number, you aren't providing a "typical" experience. You are blending a five-minute DNS blip with a six-hour database corruption. By examining the mttr median vs mean across millions of real-world incidents, we can see exactly why this "middle-ground" number is a fiction—and what is actually happening in the "unseen" half of your system's failures.
The 10x lie in one number: Median 1.9 min vs Mean 21.9 min
The most striking evidence of the mttr median vs mean divide comes from the June 2026 Oh Dear dataset, which analyzed 1,817,403 confirmed outages. The study found that the median time to resolve is just 1.9 minutes. However, the mean (the "average" MTTR most teams report) was 21.9 minutes.
This 10x gap is not a rounding error; it is a signal of extreme skew. If your dashboard says "Average MTTR: 22 Minutes," you are communicating a number that represents almost no one's reality. Most of your users (over 50%) experienced an outage that was over in less than two minutes—likely handled by a retry or an automated failover. On the other end, a small handful of users were trapped in a multi-hour outage that the average "drags down" and obscures.
Key Takeaway: Incident metrics must shift to percentile-based reporting (P50, P95, P99) because a single MTTR average hides the 10x skew between routine blips and catastrophic outages.
Why averages fail on power-law data
Statistically, mttr misleading metric is a frequent topic of debate because incident durations follow a "fat-tail" or power-law distribution. In a standard normal distribution (a bell curve), the mean, median, and mode are the same. If you are measuring the height of humans, the average is a useful proxy.
However, according to the VOID Report 2024, incident data is not a bell curve. It is a distribution where the most frequent events are extremely short, but the rarest events are orders of magnitude longer. When you calculate a mean on this data, the "six-hour outage" carries as much weight as 180 "two-minute outages."
Using mean time to resolve statistics attempts to smooth out volatility that shouldn't be smoothed. It leads to "outlier bias," where a single bad weekend from three months ago makes your current team look incompetent, even if they've handled 99% of incidents in record time since then.
The tail is the job: 0.3% of outages carry the cost
If 98.6% of outages in the 1.8M-incident study were resolved in under an hour, why do we focus so much on the metrics? Because the tail is where the business dies.
The study shows that the slowest 0.3% of incidents—the ones that run past the six-hour mark—account for a massive share of total downtime and technical debt. These are the incidents that result in SLA payouts, executive-level post-mortems, and customer churn.
A "good" MTTR can actually be a dangerous signal. If your mean is trending down, it might just mean you are getting faster at resolving trivial things while your systemic "tail" risks are growing. To be effective, SREs must separate the "noise" (automated recoveries in the <5m range) from the "work" (complex investigations in the >60m range).
68% start outside working hours: Your exposure is a 2am slow burn
The Oh Dear data highlights a brutal reality for global infrastructure: 68% of outages start outside the 9-to-6 local workday. This dramatically changes the "real" resolution time for teams without 24/7 "follow-the-sun" coverage.
An incident that occurs at 2:00 AM may have a "Technical MTTR" of 10 minutes (the time from the engineer logging in to the fix being deployed), but its "Effective MTTR" for the business is 4 hours and 10 minutes.
This outage duration distribution reveals that the primary bottleneck in resolution isn't the deployment of the fix—it's the time-to-understanding and the cognitive load of a tired engineer waking up to a series of alerts. When 7 out of 10 outages happen while the team is asleep, the ability to automate the "investigation" phase becomes the only way to manage the tail.
The half your dashboard never sees: 23.3% silent failure rate
The most damning finding for traditional MTTR dashboards is what they miss entirely. The Oh Dear data suggests that 23.3% of monitored sites had a scheduled job (cron job, queue worker, or background task) silently fail or skip within a 30-day window.
These aren't "incidents" in the traditional sense because they don't always trigger an immediate 500 error or a high-severity alert. They are silent failures. Since an incident is never "opened" in an incident management tool, these failures never enter the MTTR calculation.
If nearly a quarter of your sites are experiencing silent failures, your incident metrics percentiles are built on a subset of the truth. You are measuring the duration of the fires you can see, while ignoring the slow-moving disasters—like a backup job that hasn't run in three weeks or a billing task that is silently skipping 5% of records.
What to report instead: The Percentile Panel
To move beyond mttr misleading metric reporting, engineering leaders should adopt a three-pillar reporting framework:
- The Percentile Panel: Stop reporting one average. Report P50 (median), P95, and P99. If P50 is 2 minutes but P95 is 180 minutes, you know your problem isn't triage speed; it's the complexity of deep-system failures.
- The Silent-Failure Count: Actively track the number of failed background jobs and "skipped" tasks that were identified and remediated. This represents proactive resilience.
- Off-Hours Exposure: Track what percentage of total downtime occurs during "off-clock" hours. If this is high, it justifies investment in better automation or on-call rotation adjustments.
What this means for staffing and automation
The skew in the data suggests that human staffing alone cannot solve the "tail" problem. You cannot reasonably ask engineers to maintain peak cognitive efficiency for the 68% of incidents that happen at 2:00 AM.
When an incident hits that 21.9-minute "mean," it's usually because the easy answers (restarts, rollbacks) didn't work. The engineer is now deep in logs, traces, and metrics. Automation in 2026 must do more than just alert; it must investigate. Understanding the "why" before the human is even paged is the only way to compress the tail of the distribution.
Reporting template for your next quarterly review
Instead of a single line for "MTTR," try this format:
| Metric | Current Period | Previous Period | Trend |
|---|---|---|---|
| Median Resolution (P50) | 2.1 min | 1.9 min | Stable |
| Tail Severity (P95) | 142 min | 210 min | Improved |
| Silent Job Failure Rate | 18% | 24% | Improved |
| Off-Hours Incident % | 71% | 65% | Increasing |
This template separates the "noise" of quick fixes from the actual "work" of resolving complex outages.
Why this matters now
The release of the Oh Dear 2026 dataset provides the first large-scale empirical evidence that matches the theoretical critiques of MTTR. As organizations move toward heavier reliance on asynchronous background jobs and distributed microservices, the "silent failure" category is becoming a greater portion of the risk profile. If you are still using 2010-era averages to measure 2026-era distributed systems, you are blind to 23% of your outages and 90% of your tail risk.
Common Pitfalls
- Alerting on Mean: Never set SLOs or alerts based on a mean. One bad incident will trigger a "violation" for weeks after the real threat is gone.
- The "Fast Fix" Trap: Focusing on reducing median MTTR often leads teams to "reboot-first, ask-later," which can destroy evidence and prevent finding the root cause of the tail incidents.
- Missing the "Silents": Many teams only count outages that affect the homepage. The 23.3% silent-job failure rate proves that "uptime" is a deeper metric than surface-level HTTP pings.
Sources & further reading
- According to Oh Dear, the gap between median and mean resolution is 10x, with the median sitting at 1.9 minutes.
- According to the National Law Review, their analysis of the 1.8M outage dataset confirms that most outages end within two minutes.
- According to DevOps.com, nearly a third of outages are "silent," originating in background tasks that don't trigger traditional site monitors.
- According to The VOID Report 2024, incident data is not normally distributed, making mean-based metrics fundamentally flawed.
- According to Resilium Labs, focusing on "Power Law" distributions is necessary for understanding modern system resilience.
In a world where 68% of incidents occur off-hours and a quarter of failures are silent, the goal isn't just to "watch" the system—it's to have a platform that understands it. At 2:00 AM, when an incident enters that dangerous "tail," an automated investigation can find the root cause and provide the evidence an engineer needs to fix it before the "mean" time is even reached. Furthermore, for that 23.3% of silent failures that traditional dashboards miss, Operate proactively identifies and opens cases for exceptions and failed jobs, ensuring that the "unseen half" of your infrastructure doesn't stay that way.