Availability by the Numbers: MTBF, MTTR, and the Nines

By Sergey Nosov

12 October 2026

In 1986, Richard Feynman served on the presidential commission that investigated the loss of the space shuttle Challenger. In his own appendix to its report, he wrote that estimates of the chance of losing a shuttle “range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management.” In this article’s terms, the engineers’ estimate was two nines of reliability per flight, and management’s was five.

Feynman spelled out what management’s number meant: one could “put a Shuttle up each day for 300 years expecting to lose only one.” The record showed which side was closer. NASA’s shuttle fleet flew 135 missions between 1981 and 2011 and lost two, Challenger in 1986 and Columbia in 2003, each with a crew of seven. That is about 1 in 68, consistent with the engineers’ estimate and nearly 1,500 times worse than management’s.

Feynman’s appendix ends with the sentence I take as this article’s rule: “For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

Software has its own version of that gap: the availability on a slide or a status dashboard, and the availability users actually get. The arithmetic of availability holds a surprise. Restoring twice as fast buys the same availability as failing half as often, and restoring is often the lever within reach. Two cautions keep that honest: some failures no fast restore can excuse, and the numbers that matter are the ones you measure, not the ones you claim.

The Formula and Its Levers

Over a long run, the share of time a system works depends on two averages: how long it runs between failures and how long it takes to come back.

A = MTBF / (MTBF + MTTR)

The letters vary. Amazon Web Services, in its 2021 whitepaper Availability and Beyond, uses MTBF for the uptime, as I do here. In 2017, Benjamin Treynor Sloss and three Google colleagues published “The Calculus of Service Availability” in ACM Queue. They write the formula as MTTF/(MTTF + MTTR), with MTTF, the mean time to failure, for the uptime. The R can stand for repair, recovery, or restore. I use restore, because what counts is the duration users experience, which the paper defines as lasting “from the start of a malfunction until normal behavior resumes.”

Take a service that runs 30 days between failures and takes 4 hours to restore. It is up 720 hours out of every 724, or 99.45 percent of the time. Double the time it runs between failures, and it reaches 99.72 percent. Or leave that alone and restore it twice as fast: 99.72 percent again. The two results are not merely close; they are identical. Availability depends only on the ratio of MTBF to MTTR, and each change doubles that ratio, from 180 to 360.

So the two levers are equal in arithmetic but not in effort. Failing half as often usually takes sustained work, from testing and design reviews to safer rollouts. Restoring twice as fast can start with an alert that fires, a written way back, and a rollback that works.

There is also a third lever, which the formula hides because it treats every failure as total. Many failures are partial: one shard, one region, or one customer goes down while the rest keep working. Google’s paper names all three levers: reduce the frequency of outages, reduce “the scope of the average outage,” and reduce the time to recover. Sharding, isolation, and graceful degradation pull this lever.

What a Nine Costs

Availability is usually quoted in nines. Google’s 2016 book Site Reliability Engineering, known as the SRE book, includes a table of the downtime each level allows. Here are the common levels, with a 30-day month:

Each nine divides the allowed downtime by ten. A four-nines uptime target allows 4.32 minutes a month. If your alert waits 5 minutes before it fires, one incident has spent the month’s allowance before anyone is paged.

Over a year, the same target allows about 53 minutes. Google’s paper shows how quickly outages use that up: “three complete outages per year that last 20 minutes each result in a total of 60 minutes of outages. Even if the service worked perfectly the rest of the year, 99.99 percent availability (no more than 53 minutes of downtime per year) would not be feasible.”

In the SRE book’s chapter “Embracing Risk,” Marc Alvidrez writes that cost “does not increase linearly as reliability increments.” An incremental improvement, he adds, “may cost 100x more than the previous increment.” Users, he notes, often cannot feel the difference: “a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability!”

So choose the nines your users can feel, and treat the gap between your target and 100 percent as a budget for change. Google calls it the error budget and spends it on launches. While budget remains, releases continue. When it runs out, releases halt while the team makes the system more resilient. Only urgent security fixes and fixes for the cause still go out. My Software Development Principles series has an entry on the error budget, including the signs of one that exists only on paper, such as running out with no consequence.

Dependencies Multiply

Few services fail alone. Most depend on others: a database, a sign-in provider, a message queue, a payment gateway. The arithmetic has two cases.

In a Chain, Multiply the Availabilities

If your service cannot work without each of its dependencies, it is up only when all of them are up. So it can be no more available than the least available thing it cannot work without. When those dependencies fail independently, multiply their availabilities. An application, its database, and its sign-in service, each at 99.9 percent, give 99.7 percent together. That is about 26 hours of downtime a year, three times the 8.76 hours of any one of them. Ten such links give 99.0 percent, or about 3.6 days a year: two nines from three-nines parts.

Google’s paper turns this into a rule of thumb, the “rule of the extra 9”: “critical dependencies must offer one additional 9 relative to your service.” The reason is the count. The paper’s example gives dependencies half of a four-nines error budget, and typical services often have about five to ten of them. So each one can fail only a tenth or a twentieth as much as the service. A dependency that cannot offer the extra nine needs a mitigation, such as serving cached results or degrading gracefully. The rule does not compound with depth: count each critical dependency once, wherever it sits in the tree.

Run the multiplication on measured numbers. The AWS whitepaper notes that “A workload built using two or three dependencies with 99.99% availability SLAs can still achieve 99.99% availability itself, or higher.” The reason: “Dependencies frequently exceed their stated availability SLA or SLO.” An SLA is a promise with a penalty attached, not a measurement. The ceiling is real, but what your dependencies actually deliver sets it.

Side by Side, Multiply the Failures

Redundancy works the other way. If any one of several copies can serve, the system is down only when all of them are down at once, so you multiply the chances of failure. Two independent copies at 99 percent are down together 1 percent of 1 percent of the time: 99.99 percent, four nines from two-nines parts. My article on combinatorics in software engineering works out the same arithmetic for quorums, where a majority of replicas must be up.

Everything rests on the word independent. One expired certificate, one shared region, or one bad configuration push can take down every copy at once. Google’s paper puts it plainly: “In the real world, the correlation is never zero.” Copies help only as far as they fail apart.

The failover has to work, too. The surviving copies must carry the whole load, and at tight targets the switch cannot wait for a person. The paper warns that “by the time you bring a human online to trigger a failover, you’ve likely already exceeded your error budget.”

Check the Numbers Yourself

The arithmetic so far fits in a few lines of JavaScript, so you can plug in your own numbers. I checked the script on Node.js 24; its comments show what it prints.

// availability.js
// Run: node availability.js

// Uptime over total time.
const avail = (up, restore) =>
  up / (up + restore);

// Minutes down a target allows.
const allowed = (target, days) =>
  ((1 - target) * days * 1440)
    .toFixed(2);

// Independent links: up only
// when every link is up.
const chain = (...links) =>
  links.reduce((a, b) => a * b);

// Independent copies: down only
// when all of them are down.
const copies = (a, n) =>
  1 - (1 - a) ** n;

// As a percent. For five nines,
// pass more digits: pct(a, 4).
const pct = (a, digits = 2) =>
  (a * 100).toFixed(digits);

// 30 days up, 4 hours to restore;
// then double the uptime; then
// restore twice as fast.
// Prints: 99.45 99.72 99.72
console.log(pct(avail(720, 4)),
  pct(avail(1440, 4)),
  pct(avail(720, 2)));

// Four nines: a month, a year.
// Prints: 4.32 52.56
console.log(allowed(0.9999, 30),
  allowed(0.9999, 365));

// Three links at three nines, and
// their hours down in a year.
// Prints: 99.70 26.3
const three =
  chain(0.999, 0.999, 0.999);
const hours = (1 - three) * 8760;
console.log(pct(three),
  hours.toFixed(1));

// Two independent copies at 99%.
// Prints: 99.99
console.log(pct(copies(0.99, 2)));

Where the Minutes Go

I split a restore into five phases: detect, rally, diagnose, fix, and verify. Each one is a place to cut minutes.

Google’s paper shows how tight the phases get at four nines. Its example service has 53 minutes a year to spend. Five critical dependencies at five nines take 26 of them together, which leaves 27 for the service’s own outages. The paper supposes four outages a year, one full and three that each reach one shard in five, for a combined weight of 1.6 full outages. That leaves 17 minutes per outage: 2 minutes for monitoring to detect and alert, 5 for the on-call responder to start investigating, and 10 to mitigate.

At four nines, then, the way back has to be fast, written down, and, as the service matures, automatic. Where 17 minutes is too tight, the paper suggests shrinking the scope of outages instead.

The review after an incident can move both MTBF and MTTR. Asking why the failure happened can prevent the next one. Asking how it was detected and what slowed the restore can shorten it, with a better alert, a better guide, or a piece of automation. My article on complicated versus complex problems explains why such a review should judge each finding from where the team stood before the incident, not with hindsight.

For Most Types of F

John Allspaw made the case for the restore lever in 2010, while at Etsy, where he later became chief technology officer. His post had a pointed title: “MTTR Is More Important than MTBF (for Most Types of F).” His thesis: “Being able to recover quickly from failure is more important than having failures less often.” He was not calling failure acceptable. His point was that failure will happen, so the response to it deserves as much time and energy as prevention, and in some cases more.

But his title carried a qualifier, and the post spelled it out: “some types of failures shouldn’t ever happen, and not all failures/degradations/outages are the same.” His example was failures that cause accidental data loss.

No restore time makes up for data that is gone for good, so decide in advance how much loss the business can accept. A compromised system is the other case: bringing it back quickly, with the attacker still inside, is not recovery. NIST’s Cybersecurity Framework 2.0 lists containing and eradicating an incident among the outcomes of its Respond function. One of its Recover outcomes reads: “The integrity of backups and other restoration assets is verified before using them for restoration.”

Count It Honestly

The formula is for reasoning about the levers, not for keeping score. The AWS whitepaper says as much: MTTR and MTBF explain what drives availability, but “their utility is not as an empirical measure of availability.”

Allspaw went further. On 17 October 2017, he patched his own post. The title, he wrote, should have been “TTR Is More Important than TBF (for Most Types of F).” His reason: “taking the statistical mean of TTR or TBF makes absolutely no sense, whatsoever. Incidents and events simply are not comparable in that way, and even if they were, the time an event starts is infinitely negotiable.”

A 2021 report puts numbers on the problem. In Incident Metrics in SRE, Stepan Davidovic, a site reliability engineer at Google, analyzed incidents from three companies and from Google. In each case, “the incidents follow a positively skewed distribution”: most end quickly, and a few drag on.

With that much variance, a year of incidents at the three companies could not reliably show a 10 percent cut in duration, and the median did no better. Google’s much larger pool could, but it mixes such different incidents that Davidovic judges the finding “not particularly useful in practice.” His conclusion: MTTx, as he calls the mean-time family, “cannot be used for many practical purposes where it has been advertised to be useful.”

A faster restore still shortens every outage it touches, and the 17 minutes in Google’s paper is a budget to design for, not a score to report. Averages do work, Davidovic notes, for large populations of similar things, such as hard drives of one model. Incidents are fewer and less alike. To judge a change, he suggests measuring the step of an incident it was meant to shorten, or studying a sample of incidents in depth.

To judge reliability, measure availability where users feel it. For its distributed services, the SRE book explains, “instead of using metrics around uptime, we define availability in terms of the request success rate.” Counted that way, four nines allows one failed request in ten thousand, not a fixed number of minutes. The AWS whitepaper adds a caution: when customers stop calling an impaired service, its success rate can rise. To catch that, it suggests a downtime rule based on demand, such as any 5-minute window in which orders fall 10 percent or more below forecast.

That is Feynman’s rule again. A dashboard that stays green while users cannot sign in is public relations.

Two Questions for Your System

First: if the system you work on failed at two in the morning, how long until someone knew? And who would know first: a monitor or a customer?

Second: is the way back written down? Pick one path your users depend on and find its alert and its troubleshooting guide. If either is missing, or nobody owns it, that is your first improvement.

Checklist

Further Reading