MTTR and Availability Calculator
Detection is usually the biggest share and the cheapest to fix.
Work out MTTR and Availability. Detection is usually the biggest share and the cheapest to fix. Counts the thing everyone forgets to count.
2,160 is a quarter of continuous operation
Availability
99.585%
360h between failures · 90 min to recover
Availability is MTBF divided by MTBF plus MTTR, so it improves either by failing less often or by recovering faster — and recovering faster is almost always the cheaper of the two. Splitting recovery into detection, response and repair is what makes that actionable: detection is frequently the largest share and it is the cheapest to fix, because better alerting is a smaller undertaking than better code. Here detection is 39% of the recovery time. A system that fails rarely and takes hours to notice can have worse availability than one that fails often and self-heals in seconds, which is the argument for optimising for recovery rather than for prevention.
How the MTTR and Availability Calculator works
Availability from mean time between failures and mean time to recovery, with recovery split into detection, response and repair. Those are three different problems, and detection is frequently the largest share and the cheapest to improve.
Also known as: mttr · mtbf · mean time to recovery · mean time to repair · mean time between failures · time to detect · time to restore · availability from mttr · incident response time · mtta
Recovering faster beats failing less
Availability is MTBF divided by MTBF plus MTTR. Both terms move it, and recovery is almost always the cheaper one to improve.
The counter-intuitive consequence is that a system failing rarely and taking hours to notice can have worse availability than one failing often and self-healing in seconds. A system failing every 360 hours with a 90-minute recovery achieves 99.59%; one failing every 44 hours with a 3-minute recovery achieves 99.89%.
Which is the argument for optimising recovery over prevention. Preventing every failure is impossible; restoring service quickly is an engineering problem with known solutions, and automated rollback is usually the largest single improvement available.
Three phases, three different fixes
Detection, response and repair are separate problems and a single combined number hides which one is costing you.
Detection is an alerting problem and it is frequently the largest share. A system where every dashboard is green while customers cannot check out is alerting on component health rather than on what users experience, and that is the fix.
Response is on-call process — who is paged, how fast they acknowledge, whether they have access and a runbook. Repair is code and tooling. Better alerting is usually a smaller undertaking than better code, which is why detection is both the biggest share and the cheapest to attack.
Why the mean is the wrong statistic
Recovery times are heavily skewed. Most incidents resolve quickly and a few take an order of magnitude longer, which drags the mean somewhere that describes neither group.
The median and the 95th percentile together describe the experience far better. The median says what a normal incident feels like; the 95th says what the bad ones cost, and that is what capacity and on-call planning should be built around.
The acronym itself is ambiguous, which does not help. MTTR is used for both mean time to repair and mean time to recovery, and they differ: restoring service with a rollback recovers without repairing. Users only experience the first, so that is the one to measure.
Where to go next
The MTTR and Availability question rarely arrives on its own. These are the ones that usually come with it:
- Uptime SLA Calculator — Each nine divides the allowance by ten.
- Error Budget Calculator — An unspent budget means you are shipping too cautiously.
- Deployment Frequency Calculator — The four metrics do not trade off — batch size explains them.
- Ring Size Calculator — Finger measurement to US, UK, EU and Japanese sizes.
Frequently asked questions
How is availability calculated from MTBF and MTTR?
MTBF divided by MTBF plus MTTR. A system failing every 360 hours and recovering in 1.5 gives 99.59% availability, which is between two and three nines.
What is the difference between MTTR and MTBF?
MTBF is how long the system runs between failures; MTTR is how long it takes to get back. Availability depends on both, and improving recovery is almost always cheaper than eliminating failures.
Why split recovery into three phases?
Because they have different fixes. Detection is better alerting, response is better on-call process, and repair is better code or tooling. Reporting one combined number hides which of the three is costing you.
What is a good MTTR?
Under an hour is the top band in most industry classifications, and the trend matters more than the absolute number. A team halving its MTTR has done something real regardless of where it started.
Does failing less often always help more?
No, and this is the counter-intuitive part. A system that fails rarely and takes hours to notice can have worse availability than one that fails often and self-heals in seconds — which is the argument for optimising recovery over prevention.
Does MTTR mean repair or recovery?
The acronym is used for both mean time to repair and mean time to recovery, and they differ: recovery is service restored, repair is the underlying fault fixed. Restoring service with a rollback recovers without repairing, and users only experience the first.
What is MTTA?
Mean time to acknowledge — from alert to a human picking it up. It sits inside the response phase and is worth separating where on-call handover is the bottleneck.
How do I reduce time to detect?
Alert on what users experience rather than on component health. A system where every dashboard is green while customers cannot check out has an alerting problem, not a monitoring gap.
Is a mean the right statistic here?
Not really, and it is what everyone uses. Recovery times are heavily skewed by a few very long incidents, so the median and the 95th percentile together describe the experience far better than the mean.
Should MTTR include the post-incident review?
No — recovery ends when service is restored. The review is important and belongs in a separate measure, since including it conflates how fast you fix things with how thoroughly you learn from them.
How does automated rollback affect MTTR?
It is usually the single largest improvement available, because it removes both diagnosis and repair from the critical path. Restoring service by reverting and diagnosing afterwards is almost always right.
What if failures are too rare to compute MTBF?
Then the figure is dominated by whichever incidents you happened to have, and a wide confidence interval is the honest reading. Rare failures are good news and bad statistics.
Put this calculator on your own site
Free to use, on any site, commercial or not. Paste this where you want it to appear. It is a plain iframe, so it works in WordPress, Squarespace, Wix, Webflow, Ghost and anything else that accepts HTML.
<iframe src="https://www.thecalclibrary.com/embed/mttr-calculator" width="100%" height="640" style="border:1px solid #e2e8f0;border-radius:12px" loading="lazy" title="MTTR and Availability Calculator"></iframe>
<p style="font:13px/1.5 system-ui,sans-serif;margin:6px 0 0;color:#64748b">Powered by <a href="https://www.thecalclibrary.com/mttr-calculator" style="color:#64748b">MTTR and Availability Calculator</a> from The Calc Library</p>The only condition is that the credit line below the frame stays in place. That one line is what pays for the tool being free — it is how anyone else finds it.
Related calculators
Uptime SLA Calculator
Each nine divides the allowance by ten.
OpenError Budget Calculator
An unspent budget means you are shipping too cautiously.
OpenDeployment Frequency Calculator
The four metrics do not trade off — batch size explains them.
OpenRing Size Calculator
Finger measurement to US, UK, EU and Japanese sizes.
Open