What is mean time to repair (MTTR)?

Mean time to repair (MTTR) is a key performance indicator that measures the average time it takes to repair a failed system, component, or service and return it to full operation. It's calculated by dividing the total repair time over a period by the number of repairs completed in that same period, and it's used across IT operations, security, and maintenance to gauge how efficiently teams recover from failures. A lower MTTR means faster recovery, less downtime, and higher availability. Because the "R" in MTTR can stand for repair, recovery, respond, or resolve, the single most important step before tracking it is agreeing on which one you mean. Each measures a different slice of the incident lifecycle, and confusing them produces numbers that look precise but drive the wrong decisions. This page leads with mean time to repair as the primary definition, explains the formula with a worked example, disambiguates the four versions of MTTR that are so often confused, shows how MTTR relates to MTBF and availability, and covers the practical levers that bring it down, including in a security operations context.

Key takeaways

MTTR measures recovery speed. Mean time to repair is the average time to fix a failed system and restore it, calculated as total repair time divided by the number of repairs.
The "R" has four meanings. Repair, recovery, respond, and resolve each measure a different phase of the incident lifecycle. Define which one you track before comparing numbers with anyone else.
Lower MTTR drives availability and cuts cost. MTTR feeds directly into the availability formula, and shorter repair times reduce downtime, which industry studies price at hundreds of thousands of dollars per hour.
Measurement discipline matters. Mixing planned and unplanned work, using ticket-close time as restoration time, or blending MTTR variants are the most common ways teams produce misleading numbers.
Automation and clear process are the biggest levers. Faster diagnosis, standardized runbooks, root cause analysis, and automated response consistently shorten MTTR, in both IT operations and security.

How to calculate MTTR

The mean time to repair formula is deliberately simple: sum the total time spent on repairs during a period and divide by the number of repairs completed in that same period.

MTTR = total repair time ÷ number of repairs

For example, if a machine failed five times in a month and the repairs took 45, 90, 30, 120, and 75 minutes, the total repair time is 360 minutes across five repairs, giving an MTTR of 72 minutes. In IT, the same math applies to outages: 15 hours of downtime across five repair incidents is an MTTR of 3 hours.

The arithmetic is easy; the discipline is in defining the boundaries. Decide clearly when the clock starts and stops (strict repair time only, or the full window from failure to verified restoration), whether you count business hours or calendar time, and apply that definition consistently so trends stay comparable.

MTTR is best tracked per asset, system, or service and then averaged, because a single organization-wide number can hide a machine or service that consistently takes far longer than the rest. Many teams also report the median alongside the mean, since one very long outage can distort an average and mask what's actually typical.

The four meanings of MTTR: repair, recovery, respond, resolve

MTTR looks like one metric but represents up to four, and the overlap is where teams talk past each other. Clarifying which "R" is in play, and documenting it, is essential before any benchmarking or SLA conversation.

Variant	What it measures	Clock: start to stop
Mean Time to Repair	The hands-on fix time: diagnosing and repairing a failed component, plus testing to confirm the fix.	From when repair work begins to when the fix is mechanically complete.
Mean Time to Recovery	How long to restore full service after a failure, including resets, restarts, and validation.	From failure onset to service fully restored and confirmed.
Mean Time to Respond	How quickly the team begins acting after an incident is detected.	From detection to the first response action.
Mean Time to Resolve	The complete lifecycle, including root cause analysis and steps to prevent recurrence.	From detection through full resolution, verification, and prevention.

A useful way to remember the difference: repair is putting out the fire, while resolve is putting out the fire and then fireproofing the house. Resolution time is always equal to or longer than repair time, because it wraps diagnosis, waiting, testing, and prevention around the hands-on fix.

In practice, teams often track several of these in parallel to see where time is actually lost. A low mean time to repair paired with a slow mean time to respond points to an alerting or escalation problem, not a repair problem.

MTTR vs MTBF, MTTF, and system availability

MTTR rarely stands alone. It's usually read against the reliability metrics that describe how often and how permanently things fail.

MTBF (mean time between failures) measures the average operating time between repairable failures. Higher is better: it reflects how reliable a system is, whereas MTTR reflects how maintainable it is.
MTTF (mean time to failure) applies to non-repairable components (a fuse, a battery, a disk you replace rather than fix) and measures expected lifespan before failure.
MTTA (mean time to acknowledge) and MTTD (mean time to detect) sit earlier in the timeline, capturing how quickly an alert is picked up and how quickly a problem is spotted in the first place.

MTTR and MTBF together determine availability, one of the most important reliability outcomes, through a simple relationship:

Availability = MTBF ÷ (MTBF + MTTR)

The implication is practical: you can raise availability either by making failures rarer (higher MTBF) or by recovering faster (lower MTTR). For a system with an MTBF of 720 hours, cutting MTTR from 8 hours to 4 measurably lifts availability, which in continuous operations translates into dozens of additional operating hours per asset each year.

Where MTTR is used: IT, maintenance, and security

The same metric shows up across three domains, with the same formula but a different object of repair.

IT operations and SRE. MTTR tracks how quickly a failed service, application, or piece of infrastructure is restored. It's tightly coupled to observability, since teams can't repair what they can't see, and to SLAs and error budgets that define acceptable downtime.
Maintenance and reliability engineering. In manufacturing and asset-heavy industries, MTTR measures how fast a failed machine or component returns to service, typically tracked in a computerized maintenance management system (CMMS) alongside MTBF to guide repair-versus-replace decisions and spare-parts strategy.
Security operations. In the SOC, MTTR is usually read as mean time to respond: the time from a confirmed detection to containment. It pairs with mean time to detect (MTTD) to describe the full window in which an adversary can operate.

Because the domains share an acronym but not a scope, a benchmark borrowed from one context rarely transfers cleanly to another. A five-hour repair target that's reasonable for heavy equipment would be a poor response target for a security incident, where minutes matter. This is another reason to define the metric locally and compare only like with like.

Why MTTR matters

MTTR is ultimately a measure of operational resilience, and its business impact is direct. Every hour of unplanned downtime carries a cost: industry research has priced a single hour of downtime at roughly $300,000 for many enterprises, rising into the millions in sectors such as healthcare, banking, and automotive manufacturing. Reducing MTTR shortens those windows, protecting revenue, customer trust, and regulatory standing: resilience frameworks such as DORA and reliability standards increasingly expect organizations to demonstrate fast, reliable recovery.

Beyond cost, MTTR is a diagnostic. Because it can be broken into detection, acknowledgment, diagnosis, repair, and verification, tracking it exposes where time is actually lost. A high MTTR might mean slow alerting, missing spare parts, thin documentation, or an inefficient repair process, and the metric tells you which. It also feeds SLAs and service level objectives (SLOs): committing to a recovery target only works if you can measure and defend it.

How to reduce MTTR

Lowering MTTR means compressing each stage of the repair cycle rather than simply pushing teams to work faster. The most effective levers are:

Standardize processes and runbooks. Documented, repeatable repair procedures and clear escalation paths remove guesswork during an incident and keep response consistent even when key people are unavailable.
Speed up detection and diagnosis. Since repair can't start until the problem is understood, continuous monitoring, observability across metrics, traces, and logs, and strong root cause analysis shrink the largest and most variable part of MTTR.
Automate response. Automation and orchestration (SOAR in security, automated remediation and runbooks in ITOps) move teams directly from signal to action, cutting manual handoffs and containing issues in seconds rather than minutes.
Ensure resources are ready. Available spare parts, current documentation, and asset history at the technician's fingertips eliminate sourcing and context-gathering delays. In IT, redundancy and failover can drive effective MTTR toward zero for critical components.
Learn from every incident. Blameless post-incident reviews and root cause analysis turn each failure into a permanent reduction in future repair time. That's the practical difference between mean time to repair and mean time to resolve.

Optimizing purely for speed can backfire, and it's worth being direct about this. Rushing to restore service can produce incomplete fixes and recurring incidents, and measuring speed alone can incentivize teams to game the number. Pair MTTR with MTBF and a resolve-oriented view so the goal is durable recovery, not just a fast clock.

Expert insight: In security, fast response depends on context, not just speed

In a security operations context, the relevant flavor of MTTR is usually mean time to respond: how fast the SOC moves from a confirmed detection to containment. The limiting factor here is rarely raw speed. It's context. An analyst who has to pivot between disconnected tools to understand what an alert means, which assets are affected, and whether the indicator is known-bad will always respond more slowly than one who has that context in front of them. Fast response is a function of how quickly a team can go from alert to understanding to action.

This is where Sekoia's approach is relevant. Sekoia is a SOC platform that unifies SIEM, XDR, SOAR, and native cyber threat intelligence (CTI) in one environment, which directly compresses response time. Native threat intelligence means a detected artifact arrives already enriched with context, so analysts spend less time working out whether something matters. Automated response playbooks let teams contain a confirmed threat, such as isolating a host or disabling an account, without manual handoffs, turning minutes of coordination into seconds of automated action. Detection content authored by Sekoia's in-house Threat Detection & Research (TDR) team and mapped to MITRE ATT&CK means alerts are higher-fidelity and easier to act on, and unifying detection and response in a single console removes the tool-switching that inflates response time. As a European vendor with a data-sovereignty posture, Sekoia adds this speed without asking teams to give up control of their data.

The takeaway for buyers: when evaluating anything that promises a lower MTTR, ask whether it shortens the fix or shortens the path to understanding. Durable improvements in response time come from context and automation working together, not from a faster dashboard alone.