MTTR Median vs Mean and Why the Average Misleads

Comparing the MTTR median vs mean is the quickest way to see how skewed incident durations are, because the two numbers only agree when outages are roughly the same length. We think most teams report the mean out of habit, and that it hides exactly the incidents that matter most.

Real outage data makes the point better than theory. A large public dataset now shows how short the typical outage is and how long the worst ones run.

In this post we cover what 1.8 million outages show, why the average misleads on skewed data, why start times matter, the failures MTTR never counts, what to report instead, and when the mean is still worth keeping.

MTTR Median vs Mean in 1.8 Million Real Outages

The monitoring service Oh Dear published The State of Website Uptime, based on 1,817,403 confirmed outages across tens of thousands of monitored sites between March and December 2025. Each outage was confirmed from two independent locations, runs from the first failed check to the first successful one, and excludes sub-minute blips.

The headline is how short the typical outage is. The median time to resolve was 1.9 minutes, and the report puts the shape of the rest like this.

Outage duration	Share of outages
Resolved within one hour	98.6%
Between one and six hours	1%
Longer than six hours	0.3%

The report describes the slowest 0.3% as the ones "that do the real damage." It does not publish a mean, and we do not estimate one from the bands, because the bands alone cannot pin it down.

A small worked example shows why the mean behaves badly here. Take 100 outages where 98 last two minutes, one lasts three hours and one lasts eight hours. The median is two minutes, the mean is about 8.6 minutes, and the two long outages account for about 77% of all the downtime.

The mean in that example describes no outage that actually happened. It is too long for the 98 quick ones and far too short for the two that hurt, which is the core problem with reporting MTTR as a single average.

The example also shows how fragile the mean is. Remove the eight-hour outage and it falls to about 3.8 minutes, while the median does not move, so a quarter's MTTR can halve or double on the luck of one incident.

Each summary statistic answers a different question about the same set of outages. We keep this comparison in front of anyone who reads a reliability report.

Statistic	What it tells us	What moves it
Mean	Total downtime divided by the number of outages	A single long outage
Median	How long the typical outage lasts	A shift in the bulk of short outages
95th percentile	How bad the slow outages get	A change in the long tail as a whole
Longest outage	The worst single event	One incident, by definition

Read together, they separate two very different stories. A team whose median is falling while its 95th percentile rises is getting quicker at easy outages and slower at hard ones, and a single mean would blend those trends into one number that hides both.

Why the Average Misleads on Skewed Incident Data

Google's SRE book makes the general point about latency in its chapter on service level objectives. "A simple average can obscure these tail latencies, as well as changes in them." Incident durations behave the same way, with many short events and a long tail.

A Google report by Štěpán Davidovič on incident metrics in SRE tests this directly. Using Monte Carlo simulation and statistical analysis, it argues that statistics such as mean time to recovery "are poorly suited for decision making or trend analysis in the context of production incidents."

Courtney Nash's work on the VOID, an open database of public incident reports, reaches a similar view. Her SREcon talk on the scary truth about incident metrics set out to demonstrate how unreliable MTTR can be.

We take a practical lesson from all three. A falling average may mean the team got faster at trivial outages while the long ones got worse, and a rising average may be one bad weekend. Neither tells a manager what to change.

None of this means incident data is useless. It means the summary has to match the shape of the data, and for durations with a long tail that means describing the typical case and the tail separately rather than averaging them together.

When Outages Start Matters as Much as How Long They Last

The same dataset shows that about 68% of outages began outside the 9-to-6 working day in each site's own time zone, on weeknights and weekends. The report frames detection coverage, not the uptime percentage, as the measure that matters for teams with that pattern.

That changes how we read resolution time. An outage at 2 a.m. can be short in the data and still cost an engineer a broken night, and an outage nobody is awake to see can run long simply because detection and response wait for morning.

The long tail is where investigation time concentrates, because the quick outages resolve themselves or with a restart. Teams without round-the-clock coverage increasingly use AI agents that investigate with evidence so the first responder wakes to a finding rather than a blank dashboard, a theme we cover in reducing on-call alert fatigue.

The Failures an MTTR Dashboard Never Counts

MTTR only measures incidents someone opened. The Oh Dear report also found that 23.3% of the cron jobs it monitors failed or missed a run in the previous 30 days.

Failures like that rarely trigger an error page or an alert, so they never become incidents and never enter the average. A backup that stopped running, or a billing job that skips records, can sit unnoticed for weeks while MTTR looks healthy.

We count them separately rather than fold them into MTTR, because their problem is detection time, not resolution time. Our guide to detecting silent failures with external expectations covers how to catch them.

What to Report Instead of a Single Average

We would replace the single MTTR line in a quarterly review with a small panel. Each number answers a different question, and none of them can be moved by one outlier alone.

• The median time to resolve, which shows the typical outage.
• A high percentile such as the 90th or 95th, which shows how bad the slow ones get.
• The count of outages longer than an hour, listed by name, because each one deserves its own review.
• The share of outages that started out of hours, which shows where detection and response coverage is thin.
• The count of silent failures found, such as missed scheduled jobs, which MTTR cannot see.

Most incident trackers can export start and resolution times, which is all the panel needs. We compute the percentiles from those exports rather than from a dashboard average, and we review each long outage with a proper root cause analysis rather than folding it into a statistic.

Targets are a separate question, which we cover in what a good MTTR is and how to set one. If the long-outage list shows diagnosis is the slow part, our guide on reducing MTTR at the diagnosis step picks up from there.

When the Mean Is Still Worth Reporting

We do not think the mean is useless. Multiplied by the number of incidents, it gives total downtime, which is the right input for cost estimates and error budgets.

Percentiles have their own weakness on small samples. A team with eight incidents in a quarter has no stable 95th percentile, and for teams that small we list the incidents individually rather than summarise them with any statistic.

The Oh Dear figures also come from external uptime checks on websites, not from internal incident records. Internal incidents include partial degradations and slow investigations that a ping never sees, so we treat the dataset as evidence about the shape of outage durations, not as a benchmark for any one team's MTTR.

Put the Median Next to the Mean on Every Report

We would put the median and the mean next to each other on the next reliability report, add the 95th percentile and the list of long outages, and explain the gap. If the mean sits far above the median, the story is in the tail, and that is where review time should go.

Comparing MTTR median vs mean is a cheap habit that changes which incidents get attention. Shortening that long tail depends on evidence, which is what Operate is for. Its agents bring logs, code history and database state together when an alert fires and cite the evidence behind each finding.