MTBF/MTTR Calculator

Calculate MTBF, MTTR, MTTA and Availability from Real Incident Data

This reliability calculator turns operational numbers into the metrics that appear in SLAs, board reports, and post-incident reviews: mean time between failures, mean time to repair, mean time to acknowledge, availability, failure rate, and the annual downtime those imply. It has eight modes, from a two-field basic calculation to a paste-in incident log analyser and a return-on-investment model for reliability work.

It is built for the people who have to defend a number: SREs setting error budgets, IT managers negotiating an SLA, engineers arguing for redundancy budget, and anyone who has been asked “what would three nines actually cost us?” Everything runs in your browser, and the tool encodes your inputs into the URL, so a configured calculation can be shared with a colleague as a link.

The Eight Modes

• Basic Metrics — MTBF from operating hours and failure count, MTTR from total repair time and repair count, and availability from the two.
• System Reliability — combine components in series or in parallel to get system-level MTBF, showing exactly how much a redundant pair buys you.
• Incident Analyzer — paste a CSV of incidents with detected, acknowledged, and resolved timestamps; the tool computes MTTA and MTTR per incident and in aggregate.
• Benchmarks — compare your figures against typical operational ranges.
• Downtime Cost — convert annual revenue, system dependency percentage, engineer count, and hourly rate into a cost per hour of outage.
• SLA Compliance — check actual availability against a committed target and see the downtime budget remaining.
• Improvement ROI — model the effect of adding redundancy, automating runbooks, or improving monitoring, against implementation and maintenance cost.
• Trend Analyzer — track whether reliability is improving or degrading over successive periods.

The Formulas

All of these are arithmetic; the difficulty is in the definitions, not the maths.

• MTBF = total operating hours ÷ number of failures. A system that ran 8,760 hours and failed 12 times has an MTBF of 730 hours.
• MTTR = total repair time ÷ number of repairs. Twelve incidents consuming 18 hours of repair give an MTTR of 1.5 hours.
• Availability = MTBF ÷ (MTBF + MTTR), expressed as a percentage. With the figures above: 730 ÷ 731.5 = 99.795%.
• Failure rate (λ) = 1 ÷ MTBF. Here, 0.00137 failures per hour.
• Reliability over time = e^−t/MTBF. The probability of surviving a 168-hour week without failure is e^−168/730 ≈ 79.4%.
• Annual downtime = (1 − availability) × 8,760 hours. At 99.795% that is 17.9 hours a year.

Two definitions cause most of the disagreement in practice. MTBF measures time between failures and applies to repairable systems; MTTF measures time to failure and applies to things you replace rather than fix, like a disk. And MTTR is ambiguous in the wild — it can mean time to repair (clock starts when work begins), time to recovery (clock starts at the outage), or time to respond. Availability calculations need time-to-recovery, measured from the moment users were affected. Using repair time instead flatters your numbers, sometimes by an order of magnitude.

The Nines Table

The step from three nines to four is where the cost curve turns vertical, and the reason is arithmetic rather than engineering culture. At four nines you have 52 minutes of budget for the entire year. Human detection, paging, and diagnosis alone typically consume more than that in a single incident, which means four nines is unreachable without automated failover — you cannot get there by responding faster.

Series and Parallel: Why Redundancy Works

Components in series all have to work for the system to work, so failure rates add: λ_system = λ₁ + λ₂ + …, and system MTBF is the reciprocal of that sum. Three components each at 3,000 hours MTBF give a system MTBF of 1,000 hours. Adding dependencies always makes a system less reliable than its weakest part, which is the mathematical statement of why microservice sprawl hurts availability.

Parallel (redundant) components fail only when all of them fail, and the improvement depends critically on repair time. For two identical units the standard approximation is MTBF_parallel ≈ MTBF² ÷ (2 × MTTR). Two units at 3,000 hours MTBF with a 1-hour MTTR give roughly 4.5 million hours — a 1,500-fold improvement. Let MTTR slip to 24 hours and the same pair drops to about 187,500 hours. The lesson embedded in that formula is that redundancy is only as good as your willingness to fix the failed half quickly. A degraded cluster nobody notices for a week is barely redundant at all.

The formula also assumes independent failures, which real systems violate. Two servers in one rack share a power feed; two instances of the same software share a bug. Correlated failure is why the measured availability of a redundant pair is always worse than the arithmetic predicts.

How to Use It

1. Start in Basic Metrics with your period’s operating hours and failure count to establish a baseline.
2. Feed the Incident Analyzer a CSV export from your ticketing or on-call system. With detected, acknowledged, and resolved timestamps you get MTTA and MTTR without hand arithmetic, and you can see which incidents are dragging the average.
3. Model the system in System Reliability. Enter each component’s MTBF and MTTR and switch between series and parallel to quantify what redundancy would buy.
4. Attach a number to downtime in Downtime Cost, using annual revenue and the share of it that depends on the system, plus engineering time consumed per hour of outage.
5. Test the business case in Improvement ROI. Toggling redundancy, runbook automation, and better monitoring against implementation and maintenance cost turns “we should invest in reliability” into a payback period.
6. Share the link. Inputs are encoded in the URL, so the person reviewing your numbers opens the same calculation rather than retyping it.

Frequently Asked Questions

What is the difference between MTBF and MTTF?

MTBF applies to repairable systems and measures the mean time between one failure and the next, including the repair. MTTF applies to non-repairable components — you replace them rather than fix them — and measures mean time until the single failure that ends their life. Using MTBF for a consumable part overstates its lifetime.

Should MTTR be measured from the outage or from when we started work?

For availability, from the moment users were affected — that is mean time to recovery, and it includes detection and response. Measuring from when an engineer began work produces a much smaller number that does not correspond to any downtime a customer experienced. Track MTTA separately if you want to see how much of the gap is detection and paging.

Does a higher MTBF always mean better availability?

No. Availability is MTBF ÷ (MTBF + MTTR), so a system that fails rarely but takes two days to recover can be less available than one that fails often and recovers in seconds. When MTTR is large, reducing it is usually the cheaper lever.

How do I get MTBF for a system I have not run for a year?

Use the operating hours you actually have — MTBF is hours divided by failures over whatever window you measured. Be honest about the confidence: three months and two failures is a very wide interval. Vendor-published MTBF figures come from accelerated testing of populations and describe a fleet average, not your individual unit.

What counts as a failure?

Define it before you measure, and keep the definition stable. Full outages only, or degraded performance too? Does a failover that customers never noticed count? Different answers give MTBF figures that differ by a factor of several, which is why comparing your number to anyone else’s is mostly meaningless.

Is 99.9% a good SLA target?

It is the common commercial default and it is achievable with a competent on-call rotation and no automated failover, since it allows 43.8 minutes of downtime a month. Whether it is right depends on what an hour of downtime costs you — the Downtime Cost mode exists to make that comparison concrete.

Is my incident data uploaded?

No. The CSV you paste is parsed in your browser and never transmitted. The share link encodes only the numeric inputs you see on screen.

What should I look at next?

The SLA/SLO calculator for error budgets, the backup recovery time calculator for RTO and RPO planning, and the RAID reliability calculator if the component you are modelling is a disk array.