What MTBF, MTTR and availability actually measure
MTBF is a rate, not a lifetime. It is the total operating time of a population divided by the number of failures that population produced, and its natural reading is the reciprocal: a drive with an MTBF of one million hours has a failure rate of one per million device-hours. Nobody expects that drive to run for 114 years. Put a thousand of them in a rack and you expect roughly one failure every 1,000 hours of running — about one every six weeks.
The distinction that trips people up is MTBF versus MTTF. IEC 60050-192, the international dependability vocabulary, reserves mean time between failures for repairable items, where the clock restarts after each repair, and mean time to failure for items you throw away, where each unit contributes one failure and then leaves the population. The arithmetic on this page is identical for both: divide operating time by failure count. Only the interpretation changes.
MTTR is the other half of the pair, and its expansion is worth arguing about. Some teams read it as mean time to repair — the wrench time only. Others read it as mean time to restore, which is what a user experiences: from the moment service stopped to the moment it came back, including diagnosis, waiting for the part, and validation. This calculator assumes you enter restore time, because that is the figure availability depends on. If you feed it wrench time you will get an availability number your users will not recognise.
Availability is what the two produce together. Over a long run, an item is up for MTBF hours and down for MTTR hours in each cycle, so the fraction of time it is up is MTBF divided by the length of the whole cycle. That single ratio is the bridge between a reliability number nobody can feel and a service level everybody can: use it with the uptime SLA downtime calculator to see the same figure expressed as an allowance in minutes.
The formula explained, term by term
Start with the estimator for MTBF. You accumulate T operating hours across the whole population — fifty servers running a year each is 438,000 hours, exactly the same evidence as one server running 438,000 hours — and you count n failures. The estimate is T ÷ n. This is the maximum-likelihood estimator when failures arrive at a constant rate, which is the assumption baked into every MTBF figure ever published.
That assumption deserves a moment. A constant failure rate means the item is in the flat middle of the bathtub curve: past infant mortality, before wear-out. It also means the exponential distribution applies, so the probability an item survives t hours is e−t/MTBF. Put t = MTBF into that and you get e−1 = 0.368. Only 37% of items survive to their own MTBF, which is the sharpest way to see that MTBF is not a service life.
MTTR uses the same shape: total restore hours R divided by the same failure count n. Using the same denominator matters. If your incident log has 6 outages but 9 separate repair visits, decide which number is the failure count and use it consistently, or availability comes out wrong in a way no reviewer will spot.
Availability follows directly. In steady state each failure costs you MTTR hours out of a cycle that lasts MTBF + MTTR hours, so uptime fraction A = MTBF ÷ (MTBF + MTTR). Two consequences fall out of the algebra and are worth holding on to. First, availability depends only on the ratio MTTR ÷ MTBF: halving repair time and doubling MTBF move availability by the same amount. Second, when MTTR is small compared with MTBF, unavailability is very nearly MTTR ÷ MTBF, which is the approximation to use in your head.
The derived rates are conversions of MTBF and nothing more. Failure rate λ = 1 ÷ MTBF. Expressed in failures per billion device-hours it becomes FIT, the unit semiconductor datasheets use, so FIT = 109 ÷ MTBF. Annualised failure rate multiplies λ by the 8,760 hours in a year: AFR = 8,760 ÷ MTBF, quoted as a percentage. AFR above 100% is not an error — it means each unit averages more than one failure per year of service.
Worked example: 50 servers over one year
You run 50 identical servers continuously for a year. Six of them failed, and your incident log shows 18 hours of restore time in total across those six events. You want next year's spares budget for a fleet you plan to grow to 500 units.
- Accumulate operating time. T = 50 units × 8,760 h = 438,000 device-hours. Note that this is device-hours, not calendar hours.
- Divide by failures. MTBF = 438,000 ÷ 6 = 73,000 hours. In years of continuous running that is 73,000 ÷ 8,760 = 8.33 years — a number to quote carefully, because it is not how long a server lasts.
- Average the restores. MTTR = 18 h ÷ 6 = 3.0 hours.
- Form availability. A = 73,000 ÷ (73,000 + 3) = 73,000 ÷ 73,003 = 0.99995891, or 99.99589%.
- Convert to downtime. Unavailability is 3 ÷ 73,003 = 4.1094 × 10−5. A year holds 525,600 minutes, so expected downtime is 4.1094 × 10−5 × 525,600 = 21.6 minutes per year.
- Count the nines. −log10(4.1094 × 10−5) = 4.39 nines — comfortably past four nines, short of five.
- Convert MTBF to rates. AFR = 8,760 ÷ 73,000 × 100 = 12.0%. FIT = 109 ÷ 73,000 = 13,699.
- Forecast the fleet. 500 units × 12.0% = 60 failures next year, which is your spares and labour planning number.
Every figure here is reproducible on paper, and the last one is the one that pays for itself: 60 failures at three hours each is 180 engineer-hours of unplanned work, which you can price with the IT downtime cost calculator.
How to read the result
Read availability in nines, not in percent, because percent hides the thing that matters. The step from 99.9% to 99.99% is only nine hundredths of a percentage point, but it removes 90% of your downtime: 8.8 hours a year becomes 53 minutes. Each additional nine is a factor of ten, and the cost of buying it usually rises by a similar factor.
Then decide which lever you are actually pulling. Because unavailability is approximately MTTR ÷ MTBF, cutting restore time from four hours to twenty-four minutes does as much for availability as making the hardware ten times more reliable — and it is almost always cheaper and faster to achieve. Automated failover, hot spares, tested runbooks and parts on site are MTTR investments. This is why the table above holds MTBF fixed and varies only MTTR: it prices the lever you can actually move this quarter.
Treat the single-item figure as a floor, not a promise. Real services are built from many components, and putting two identical items in parallel with automatic failover squares the unavailability — two units at 99.9% each give 99.9999% for the pair, if the failover really works and the failures really are independent. Work that out properly with the series and parallel availability calculator, and remember that a shared power feed, a shared rack, or a shared firmware bug destroys the independence the arithmetic assumes.
Finally, compare AFR against the vendor's. Datasheet MTBF figures come from accelerated life testing or a parts-count prediction under standards such as MIL-HDBK-217F or Telcordia SR-332, under stated temperature and duty assumptions. Field studies of large disk populations, notably Schroeder and Gibson's FAST 2007 analysis, found replacement rates in production well above the rates implied by datasheet MTBF, in some populations by close to an order of magnitude. Your own AFR describes your environment; the datasheet describes a laboratory.
Availability, downtime and the repair time it takes
| Availability | Nines | Downtime per year | Downtime per 30-day month | MTTR needed at MTBF 73,000 h |
|---|---|---|---|---|
| 90% | 1 | 876 h (36.5 days) | 72 h | 8,111 h |
| 99% | 2 | 87.6 h (3.65 days) | 7.20 h | 737 h |
| 99.9% | 3 | 8.76 h | 43.2 min | 73.1 h |
| 99.95% | 3.3 | 4.38 h | 21.6 min | 36.5 h |
| 99.99% | 4 | 52.6 min | 4.32 min | 7.30 h |
| 99.999% | 5 | 5.26 min | 25.9 s | 43.8 min |
| 99.9999% | 6 | 31.5 s | 2.59 s | 4.38 min |
The right-hand column is the practical message: at a fixed MTBF of 73,000 hours, five nines requires restoring service inside 44 minutes, every time.
MTBF is not a service life and not a warranty
A one-million-hour MTBF does not mean the item lasts 114 years, and it does not mean it will not fail tomorrow. Under the constant-rate assumption behind every MTBF figure, the chance an item is still working after one MTBF is e−1 = 36.8%. The figure also says nothing about wear-out: SSD endurance, fan bearings, battery capacity and capacitor ageing all have a finite service life that the manufacturer states separately, and MTBF is only valid inside that life. Quoting MTBF as a lifespan in a customer document is the fastest way to lose an argument with a reliability engineer.
Mistakes that make these numbers wrong
- Using calendar hours instead of operating hours. A device powered off for three months of the year contributed no exposure. Count powered-on hours, or your MTBF is inflated by the idle time.
- Mixing failure counts and repair counts. MTBF and MTTR must share the same denominator. Repeat visits to one incident are one failure, not three.
- Quoting inherent availability as if it were operational availability. This formula counts corrective maintenance only. Add preventive maintenance windows, parts logistics and approval delays and the achieved figure drops, sometimes by a whole nine.
- Estimating from a handful of failures. The standard chi-square bounds on MTBF stay wide until the failure count grows: at two failures the 90% interval spans more than a factor of ten, and at ten failures it is still around a factor of three. Report the interval, or report an order of magnitude.
- Reporting an infinite MTBF because nothing failed. Zero failures does not mean infinite reliability. Reliability practice is to quote a one-sided lower confidence bound from the accumulated hours instead.
- Assuming component MTBFs are independent. A shared power supply, a shared cooling loop or a common firmware defect makes two "redundant" units fail together, and the parallel arithmetic collapses.
- Ignoring the wear-out region. Once an item is past its rated service life the constant-rate model no longer holds and MTBF understates the failures you will see.
Where this sits among the other reliability tools
MTBF and MTTR are the two inputs almost every other reliability calculation consumes. Once you have them, availability for a single item comes from this page; availability for an architecture — two power feeds, three replicas, a load balancer in front — comes from combining items in series and parallel. Series combination multiplies availabilities and always lands below the weakest member, which is why a chain of six 99.9% components delivers 99.4%.
If you run services rather than hardware, the modern framing is the error budget: an SLO of 99.9% over 30 days grants 43.2 minutes of permitted unavailability, and each incident spends part of it. The SLO error budget calculator converts a target into a budget and tracks the burn, which is a more actionable form of the same arithmetic than a nines figure on a slide.
For data rather than service, availability is the wrong metric entirely — what matters is how much work you lose and how long recovery takes, which is the recovery point and recovery time objective pair handled by the RPO and RTO data loss calculator. And when you are sizing an array, the AFR you derive here is exactly the input a rebuild-window risk model needs, alongside the capacity arithmetic in the RAID capacity calculator.
For prediction rather than measurement — a figure for hardware that does not exist yet — the parts-count and parts-stress methods in MIL-HDBK-217F and Telcordia SR-332 sum component failure rates into a system λ. Those predictions are useful for comparing two designs. They are not a substitute for the field data you collect once the thing is running, and where the two disagree, the field data is the one that describes your world.
Key terms
- Inherent availability (Ai)
- Availability counting corrective maintenance only, MTBF ÷ (MTBF + MTTR). It is the design-level figure and the optimistic one.
- Operational availability (Ao)
- Uptime ÷ total calendar time, counting everything: corrective work, preventive work, logistic delay, administrative delay, standby. Always at or below inherent availability.
- FIT
- Failures in time — failures per 109 device-hours. 1,000 FIT equals an MTBF of one million hours.
- AFR
- Annualised failure rate — the expected fraction of a population that fails per year of continuous service, 8,760 ÷ MTBF.
- Bathtub curve
- The three-phase hazard-rate picture: falling infant mortality, a flat useful-life region where the constant-rate model applies, then rising wear-out.
- Logistic delay
- Time spent waiting for a part, a courier or an engineer. Excluded from inherent availability, included in operational availability, and usually the largest share of a long restore.