Mean time to resolve (MTTR) is the average time to fully resolve a failure, including detection, diagnosis, repair, and the work that prevents a repeat. Divide total resolution time by the number of incidents. The same math tracks security vulnerabilities. Set your start and stop points first, because MTTR also stands for repair, recovery, and respond.
This guide covers incident response and vulnerability remediation. You get the definition, the formula, a worked example, benchmarks, eight ways to reduce resolution time, and a reporting approach that holds up in a board review.
What is mean time to resolve?
Mean time to resolve is the average time your team needs to fully resolve a failure. The clock covers four activities: detecting the failure, diagnosing it, repairing it, and finishing the follow-up work that stops it from happening again. It applies to unplanned incidents, not to planned service requests.
The same measure applies to a vulnerability in your code. Instead of an outage, you track a finding. The question stays the same: how long did it stay open?
The four meanings of MTTR (repair, recovery, respond, resolve)
The R in MTTR stands for one of four words. The four measures overlap, and each starts and stops its clock at a different point.
Source: Atlassian, common incident management metrics.
In application security, MTTR often stands for mean time to remediate: the time from detecting a vulnerability to fixing it.
Why the definition you choose changes your numbers
One incident produces four different MTTR values. Take an outage that begins at 02:00. An alert fires at 02:20. An engineer starts work at 02:30. A rollback restores service at 03:30. The permanent fix ships and is verified at 15:00 the next day. The table shows whether each clock includes each segment.
The same incident reads as one hour or 37 hours. Neither number is wrong. They answer different questions: how fast your team repairs a system, and how long a failure takes to fix for good.
Three more choices move the number: wall-clock time versus business hours, which severities are in scope, and whether a reopened ticket restarts the clock. Write each choice down, publish it with the metric, and keep it fixed. A number without its definition does not survive a review.
How to calculate MTTR
The MTTR formula divides total resolution time by the number of incidents in a period.
The formula
MTTR = total resolution time ÷ number of incidents
Follow five steps:
- Choose one definition: repair, recovery, respond, or resolve.
- Set the start and stop events, such as "alert fires" and "fix verified in production."
- Pick a period and a scope, such as one quarter and all severity 1 and 2 incidents.
- Measure the duration of each incident that closed in that period.
- Add the durations and divide by the number of incidents.
For vulnerabilities, use the same formula with fix time: the sum of (fix date − detection date) for every vulnerability fixed in the period, divided by the number fixed.
Worked example
Your team closed four incidents last month.
The total is 260 minutes. Divide by four incidents: 260 ÷ 4 = 65 minutes. Your MTTR is 65 minutes.
Now add a fifth incident that took 20 hours (1,200 minutes). The total becomes 1,460 minutes, and MTTR becomes 1,460 ÷ 5 = 292 minutes, or 4 hours 52 minutes. One incident multiplied the mean by about 4.5. The median, the middle value, moved from 65 to 75 minutes.
Report both numbers. The mean shows total impact. The median shows the typical incident.
Common measurement mistakes
- Letting outliers drive the story. One long incident swamps the mean. Report the median and the 90th percentile, the value that 90% of incidents beat, next to MTTR.
- Counting reopened tickets as new incidents. A reopened ticket means the first fix failed. Keep the original start time and extend the same incident, or your MTTR rewards premature closure.
- Leaving start and stop times vague. "Detected" can mean the alert, the page, or the ticket creation. Name the system and the timestamp that define each event.
- Mixing severities. A blended average hides the severity 1 incidents that matter most. Segment by severity.
- Mixing clocks. Wall-clock hours and business hours give different answers for the same incident. Pick one and state it. Atlassian notes that teams most often calculate resolution time in business hours.
- Counting only what closed. Open items never enter the average. Track the age of open items next to MTTR so a growing backlog cannot hide behind a good number.
MTTR vs. related metrics
MTTR is one clock in a set. MTTR vs. MTTD, MTTA, MTBF, MTTF, and change failure rate is a question of which part of the failure timeline each metric covers.
- MTTD and MTTA are the first two segments of the timeline. Cut them, and MTTR drops whenever its clock starts at the failure.
- MTBF and MTTR set availability. Availability = MTBF ÷ (MTBF + MTTR). Raise MTBF or lower MTTR, and uptime improves.
- MTTF and MTBF differ by what you can repair. Use MTTF for parts you replace and MTBF for systems you repair.
- Change failure rate shows how often your own changes cause the failures that MTTR then measures.
What is a good MTTR?
No single number is good. The right target depends on severity, the service, and which MTTR you track. Start from your own baseline, set targets by severity, and use public benchmarks for direction. DORA cautions against comparing metrics between vastly different applications, such as a mobile app and a mainframe system.
Benchmarks by severity
Severity decides how fast you must act. The table shows example targets. Treat them as a starting point, not an industry standard, and tune them to your service level agreements (SLAs) and service level objectives (SLOs).
Two clocks per severity keep the definitions honest. Restore service fast, then fix the cause for good.
MTTR in DevOps: the DORA view
DevOps teams most often meet MTTR through DORA, the DevOps Research and Assessment program run by Google Cloud. (DORA here is not the EU Digital Operational Resilience Act. For that regulation, read DORA and the code you ship.)
DORA now measures this clock as failed deployment recovery time: the time it takes to recover from a deployment that fails and requires immediate intervention. In 2023, DORA renamed and redefined the metric once called mean time to recover, or time to restore service. Earlier definitions did not distinguish between a failure caused by a software change and a failure caused by external factors, such as a data center outage.
Source: DORA, 2024 Accelerate State of DevOps Report, page 13.
Treat the levels as a snapshot. DORA states, "We do not set these levels in advance," and the clusters shift from year to year. The 2023 report placed medium performers between one day and one week, and low performers between one month and six months. The 2025 report groups teams into seven profiles rather than four levels. Use the levels for direction. DORA also warns against treating a metric as a goal, comparing unlike applications, and competing against other teams.
Why MTTR matters
MTTR links reliability and risk to one number that engineering, security, and finance can all read. Four effects explain why it belongs on your dashboard.
Customer impact
Customers feel duration. Impact grows with how often something breaks, how many people it reaches, and how long it stays broken. MTTR measures the last factor, and every incident gives you a chance to shorten it.
Cost of downtime
Downtime has a price you can quote. ITIC's 2024 survey of more than 1,000 firms found that one hour of downtime costs more than $300,000 for over 90% of mid-size and large enterprises. Of enterprises surveyed, 41% put the hourly cost at $1 million to more than $5 million. The figures are self-reported and exclude litigation and penalties. Multiply your own hourly cost by the hours you cut from MTTR to size the benefit.
Security exposure window
A vulnerability stays dangerous from the day an attacker can exploit it until the day your fix runs in production. That span is your exposure window, and your resolution time is the part you control.
Attackers work inside that window. Exploitation of vulnerabilities was the most common initial access vector in Verizon's 2026 Data Breach Investigations Report, at 31% of non-error, non-misuse breaches, up from 20% a year earlier. Mandiant estimates that mean time to exploit has dropped to -7 days, which means exploitation routinely begins before a patch is released.
Developer productivity
Late fixes cost more than early ones, because context fades. Research by Gloria Mark at the University of California, Irvine found that workers took about 23 minutes on average to resume interrupted work, after handling other tasks in between. An issue that returns to a developer days after merge forces that cost plus the time to reload the code. Fix an issue while its author still holds the context, and you avoid that reload.
MTTR for security vulnerabilities
Vulnerability MTTR measures how long a vulnerability stays open: the average time from detection to a verified fix. Security teams often call it mean time to remediate. The arithmetic matches incident MTTR, but the clock behaves differently.
Remediation time vs. incident time
The last two rows change the math. Accepted risks and false positives are not fixes, so exclude them from MTTR and count them separately.
SLAs by severity
A vulnerability service level agreement (SLA) sets the maximum time to fix a finding at each severity. Public references differ, including where the clock starts.
Sources: CISA BOD 19-02, FedRAMP notice on BOD 26-04, Tenable on BOD 26-04, PCI Security Standards Council FAQ 1597.
BOD 19-02 counted from initial detection. PCI DSS counts from patch release. Choose your own start event on purpose, write it down, and apply it to every tier.
Example internal tiers follow. They are examples only. Align them with your risk policy and your regulators.
Track two numbers per tier: MTTR and the share of findings fixed within SLA.
How a vulnerability's time open drives risk
Risk grows while a vulnerability stays open. Exploitability sets how fast, and exposure sets how many attackers can reach it. Time open is the variable your team controls.
The data shows where defenders stand. Verizon found that only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities (KEV) catalog had been fully remediated, and it reported a median time of 43 days. Veracode's 2026 State of Software Security report found that 82% of organizations now carry security debt, its term for flaws that stay unresolved over time.
Measure time open for every vulnerability, including those still open. Report MTTR for what you closed, and report age for what you did not.
What makes MTTR high?
Look for time lost between steps before you look for slow work inside one step. Check these six causes first, and map each to a segment of the timeline: detection, acknowledgment, repair, or permanent fix.
- Late detection. Problems found in production or in an audit have been open longest. Detection lag counts toward MTTR whenever the clock starts at the failure.
- Poor triage. Alerts and findings without severity, context, or exploitability data wait in a queue while teams debate priority.
- Unclear ownership. A finding with no owner has no one racing to fix it. Time disappears in handoffs and escalations.
- Context switching. A late-found issue pulls a developer away from current work and forces them to reload old code.
- Slow review and deploy cycles. A fix that waits days for review, a build, or a release window is still an open problem.
- Missing fix guidance. When a report says what is wrong but not how to fix it, diagnosis becomes research.
8 ways to reduce MTTR
Each practice shortens one segment of the timeline. Start with the segment your data shows is longest.
Shift detection left
Find problems where they cost least to fix. Run code analysis in the IDE and on every pull request, so issues surface minutes after they are written, while the author still has context. SonarQube for IDE flags issues as you type, and SonarQube analyzes pull requests in your CI/CD pipeline. The fix then ships with the change instead of weeks later. Read more in What is shift left?
Automate triage and routing
Remove the human queue between detection and the person who can fix it. Route alerts by service and severity to the right on-call rotation. Route code findings to owners through code ownership files, and assign them on creation. Rank vulnerabilities by exploitability as well as severity. SonarQube Advanced Security checks dependency risks against the CISA KEV catalog and adds exploitability predictions, so you sort by what attackers are likely to use.
Give actionable fix guidance
A finding that explains the fix removes the diagnosis step. SonarQube rules explain why an issue matters and show compliant and noncompliant code examples. The SonarQube Remediation Agent goes further: it takes issues from your backlog, generates fixes, re-checks each one in a sandbox, and opens pull requests for review. For incidents, the equivalent is a dashboard that links a failing service to its latest deploy, plus a runbook that names the next step.
Integrate in the IDE and the pull request
Put feedback where developers already work. SonarQube for IDE shows issues beside the code. On the pull request, SonarQube reports the quality gate result, so reviewers see problems before merge. Gitar reviews pull requests, fixes CI failures, and verifies the result until the build passes. Fewer tool switches mean fewer hours between detection and fix.
Use quality gates
Stop new problems at the door. A quality gate is a set of pass or fail conditions on measures such as new issues, coverage on new code, and duplication. On a pull request, SonarQube checks the gate against new code, shows the result, and can block a merge or fail a CI pipeline. Fewer defects reach production, so fewer incidents start there. See Understanding quality gates.
Write runbooks
A runbook turns diagnosis into lookup. For each common failure, record the symptoms, the checks, the safe mitigations, the rollback command, the owner, and the escalation path. Review the runbook after every incident that used it. Do the same for recurring vulnerability classes, such as a dependency upgrade or a secret rotation.
Run blameless postmortems
Resolution is not complete until the failure cannot repeat. Hold a blameless postmortem after each significant incident, focus on system causes, and give every action item an owner and a date. Track those items to closure, because mean time to resolve includes the work that prevents a repeat.
Track trends
A number you report once cannot guide improvement. Review MTTR monthly by severity and service, with the median and the 90th percentile, and compare each against its target. When a number moves, find the segment of the timeline that changed. The next section shows how to set that up.
How to track and report MTTR
Dashboards
Show five things:
- MTTR, median, and 90th percentile by severity.
- A trend over at least 90 days.
- The count of incidents or findings behind each number.
- The age of open items.
- The share of items resolved within SLA.
Always show the count. An MTTR built from three incidents is an anecdote, not a trend. Pull timestamps from your incident tool, monitoring, CI/CD pipeline, and code analysis. For code issues and dependency risks, SonarQube dashboards report MTTR directly.
Cadence
Targets
Set targets by severity, and measure progress against your own baseline before you compare with anyone else. Do not turn MTTR into an individual performance score. DORA cautions that setting a metric as a goal invites gaming, in line with Goodhart's law. Pair MTTR with a balancing metric, such as change failure rate for incidents or reopen rate for vulnerabilities, so speed does not cost quality.
A defensible board number carries four things: the definition, the severity scope, the median next to the mean, and the sample size.
Sonar and MTTR
SonarQube is the independent verification layer for your code. It finds issues in the IDE and on every pull request, and it reports how long your teams take to close them.
SonarQube measures MTTR for issues in your code and dependencies, not for production incidents. Each measure follows the definition printed on the dashboard:
- Project health dashboard. Tiles show MTTR for newly introduced security, reliability, and maintainability issues: the average time to resolve issues that were introduced and detected in the last 30 days and closed in that same period. An issue counts as closed when it no longer appears in a later analysis. Open, accepted, and false positive issues are excluded.
- Custom and portfolio dashboards. Widgets show MTTR for issues, MTTR for newly detected issues within 30 days, and MTTR for dependency risks, including risks that are fixed or marked safe. The dependency risk widget requires SonarQube Advanced Security.
Read MTTR next to the open issue count, because the measure covers resolved issues only. Then use the same dashboards to see whether the practices above move the number: feedback in the IDE, quality gates on every pull request, and fixes from the SonarQube Remediation Agent.
Availability depends on product and plan. On SonarQube Cloud, the project health dashboard is available on all plans, and custom and portfolio dashboards require the Enterprise plan. On SonarQube Server, the documentation lists dashboards in Enterprise edition and higher. See the dashboard documentation for SonarQube Server and SonarQube Cloud.