MTTR (mean time to repair, or in security, mean time to remediate) measures how quickly you fix something after it fails. MTBF (mean time between failures) measures how long a system runs before it fails again. You want MTTR to go down and MTBF to go up. MTTR tells you how well you respond; MTBF tells you how well you prevent.
Both metrics come from reliability engineering, but they map cleanly onto application security. This guide defines each one, shows the formulas, explains how they translate to vulnerabilities, and covers practical ways to improve both.
What is MTTR?
MTTR is the average time it takes to get from a failure back to a working state. The "R" has several expansions, and teams often mean different things by it:
| Expansion | Usually measures | Common in |
|---|
| Mean time to repair | Time spent actively fixing the failed component | Maintenance, hardware |
| Mean time to recover / restore | Time from failure until service is back | SRE, DevOps |
| Mean time to respond | Time from alert until someone starts working on it | Incident response, SOC |
| Mean time to resolve | Time until the issue is fully closed, including follow-up | IT service management |
| Mean time to remediate | Time from detecting a vulnerability until it's fixed | Vulnerability management, AppSec |
Pick one definition, write it down, and use it consistently. Two teams reporting "MTTR" with different expansions can't be compared.
The general formula:
MTTR = total repair (or remediation) time ÷ number of repairs (or remediated issues)
Example: your team fixed four critical vulnerabilities this month. They took 2, 3, 5 and 30 days from detection to deployed fix. MTTR is (2 + 3 + 5 + 30) ÷ 4 = 10 days. Notice that one slow fix dominates the average, which is why the median (4 days here) is worth reporting next to it.
What is MTBF?
MTBF is the average operating time between one failure and the next. It describes reliability: how often something breaks.
MTBF = total operating time ÷ number of failures
Example: a service ran for 720 hours in a month and had three failures. MTBF is 720 ÷ 3 = 240 hours.
MTBF is meant for things that get repaired and returned to service. For components that are replaced rather than repaired, reliability engineers use a related metric, mean time to failure (MTTF).
MTTR vs MTBF at a glance
| MTTR | MTBF |
|---|
| Question it answers | How fast do we fix a failure? | How often do failures happen? |
| Direction you want | Lower | Higher |
| What it reflects | Response and remediation capability | Prevention and quality |
| Formula | Total repair time ÷ number of repairs | Total operating time ÷ number of failures |
| Improved by | Faster triage, ownership, fixing and deployment | Better design, testing and root-cause fixes |
People sometimes search for how to "reduce MTTR and MTBF." In practice you reduce MTTR and increase MTBF. A falling MTBF means failures are getting more frequent.
How MTTR and MTBF relate to availability
Together, the two metrics give a standard estimate of availability:
Availability = MTBF ÷ (MTBF + MTTR)
With an MTBF of 240 hours and an MTTR of 2 hours, availability is 240 ÷ 242, or about 99.2%. You can improve availability by failing less often, recovering faster, or both.
Where DORA metrics fit
The DORA research program used "mean time to restore" as one of its original software delivery metrics. DORA now calls it failed deployment recovery time: "the time it takes to recover from a deployment that fails and requires immediate intervention." DORA's change fail rate plays a role similar to MTBF, measuring how often deployments cause problems.
How MTTR and MTBF apply to security
Swap "failure" for "vulnerability" and both metrics become security metrics.
MTTR in security: how long you stay exposed
In vulnerability management, MTTR usually means mean time to remediate: the average time from detecting a vulnerability to deploying the fix. It's the closest single number to "how long are we exposed." Teams typically report it by severity or risk tier, because the MTTR for criticals matters far more than the MTTR for informational findings.
It pairs naturally with mean time to detect (MTTD), which measures how long a vulnerability exists before you find it. MTTD plus MTTR is your total exposure window.
MTBF in security: how often new risk lands
MTBF isn't a standard vulnerability management metric, but the idea behind it is useful. The security equivalent asks: how often does a new critical vulnerability reach production? A program that fixes quickly but keeps shipping the same bug class has a good MTTR and a poor "MTBF."
Ways to measure it:
- Time between new critical findings in production, per service or team.
- Recurrence rate: how often a vulnerability class you already fixed comes back.
- Escape rate: the share of criticals found after merge rather than in the pull request.
Why you need both
MTTR alone rewards a team that's good at firefighting. MTBF alone rewards a team that ships so little nothing breaks. Tracking both shows whether you're getting faster at fixing and introducing less risk in the first place.
How to improve MTTR and MTBF in security
Lower MTTR: remove the waiting
Most remediation time is spent waiting, not fixing. Findings wait to be triaged, then for an owner, then for a pull request someone trusts enough to merge. The biggest gains come from:
- Triaging on reachability and exploitability, so the critical queue holds only findings that matter.
- Routing to the code owner (commit author, then
CODEOWNERS) instead of a team backlog. - Delivering fixes as pull requests that already pass the build and tests, with a human approving the merge.
- Escalating stalled fixes automatically against a risk-based SLA.
We go deeper on each step in how to reduce MTTR for critical vulnerabilities.
Raise MTBF: stop the same failure from coming back
- Fix the root cause, not the symptom. A fix that blocks one payload but leaves the unsafe pattern in place will fail again.
- Scan every pull request, so new vulnerabilities are caught before they merge and never count as production failures.
- Eliminate whole classes at once. If a vulnerable dependency or unsafe helper shows up across many repositories, fix it everywhere in one campaign.
- Run post-incident reviews for criticals and turn each lesson into a check, a secure default or a library change.
- Watch recurrence. If a class you closed comes back, the earlier fix didn't reach the root cause.
Common mistakes with MTTR and MTBF
- Mixing MTTR definitions. Repair, recover, respond, resolve and remediate measure different spans of time.
- Reporting the mean alone. One outlier can swing either metric. Add the median and 90th percentile.
- Counting suppressions as fixes. Closing a finding as "accepted risk" lowers MTTR without lowering exposure.
- Tracking MTTR without the open backlog. MTTR only includes findings that were fixed. Old, open criticals disappear from the number unless you track their age too.
- Trying to "reduce" MTBF. A shorter time between failures is worse, not better.
How Nullify reports and improves MTTR
Nullify's Security Program Management keeps one prioritized backlog across code vulnerabilities, leaked secrets, cloud misconfigurations, supply-chain risks and validated pentest findings, each scored 0–100 on severity, exploitability, reachability and business impact. It reports MTTR, current finding counts, campaign progress, per-team progress and SLA compliance.
To bring MTTR down, it routes work to owners based on CODEOWNERS, commit history and current workload, and escalates stalled security PRs through Slack with the risk and SLA stated. To stop the same issues recurring, it runs campaigns that target a whole class of findings, such as eliminating leaked secrets or upgrading CVE-affected dependencies. Learn more about security program management.
Frequently asked questions
What is the difference between MTTR and MTBF?
MTTR measures how long it takes to fix a failure once it happens. MTBF measures how long a system runs between failures. You want a low MTTR and a high MTBF.
Should MTBF be high or low?
High. A higher MTBF means failures happen less often. A falling MTBF means reliability is getting worse.
What does MTTR stand for in security?
In vulnerability management it usually means mean time to remediate: the average time from detecting a vulnerability to deploying the fix. In incident response it can mean mean time to respond or recover, so define it before you report it.
How do you calculate availability from MTBF and MTTR?
Availability equals MTBF divided by the sum of MTBF and MTTR. For example, an MTBF of 240 hours and an MTTR of 2 hours gives about 99.2% availability.
What is the difference between MTTD and MTTR?
Mean time to detect (MTTD) measures how long an issue exists before you find it. MTTR measures how long it takes to fix after you find it. Added together, they describe your total exposure window.
