Mean time to resolution
Mean time to resolution is the average time between a defect or incident being reported and it being resolved. It is the total elapsed time across all resolved items divided by their count, and it is abbreviated MTTR. Teams track it to see whether bugs and outages are closed faster or slower over time.
The longer version
MTTR is used for at least four measures, and a number quoted without its meaning cannot be compared. Mean time to repair covers the hands-on fixing of a failed component. Mean time to recovery, or to restore, runs from the failure until service is back, whether or not the cause is fixed. Mean time to respond counts from the alert until someone acts. Mean time to resolve, the sense used here, runs from the report until the problem is closed for good. Two teams that both say MTTR may be timing different stretches of the same incident.
The calculation is simple: add the time each item took and divide by how many there were. The decisions around it are not. The clock can start when the problem began, when monitoring noticed it or when a customer reported it, and it can stop at a deployed fix, a confirmed fix or a closed ticket. Reopened items raise the question of whether they restart the clock. The team should write those choices down once, so the trend means the same thing in March as in September.
A mean is pulled by its extremes. One bug that sat open for ninety days outweighs a dozen fixed in an hour, so the median, or a split by severity, usually describes a typical item better than the average does. The measure can also be gamed by closing tickets quickly and reopening them, or by resolving easy reports first. It is best read next to the share of defects that escape to production and the root causes found, which the five whys technique is often used to reach.
Common questions
What does MTTR stand for?
Here MTTR means mean time to resolution, and the same letters are also used for mean time to repair, mean time to recovery and mean time to respond. The four measure different stretches of an incident, so a team quoting MTTR should say which one and where its clock starts and stops.
How do you calculate mean time to resolution?
Add up the time from report to resolution for every item resolved in a period, then divide by the number of items. If five bugs took 2, 4, 6, 8 and 30 hours, the total is 50 hours and the mean is 10 hours. Choose the start and end points in advance and apply them to every item.
What is a good MTTR?
A good figure depends on severity, system and team, so no single number serves as a target. Critical outages are expected to resolve in hours, while low-severity cosmetic bugs may sit in a backlog for weeks without being a problem. The useful comparison is a team's own trend by severity band over time.
Why is the median sometimes better than the mean for resolution time?
The mean is distorted by a few very slow items, so a single long-lived bug can hide an otherwise fast process. The median is the middle value and ignores those outliers, which makes it a better picture of a typical case. Many teams report both, or the median by severity.
How can a team reduce mean time to resolution?
Reports that arrive with the evidence needed to reproduce the problem cut the investigation phase, and triage that assigns an owner on the day of the report cuts the waiting phase. Clear severity rules, on-call ownership and root cause analysis that removes repeat incidents all shorten the average without rushing the fix.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.