Reliability: MTBF, MTTR, and Why It Isn't Availability
Why this matters: availability and reliability get used interchangeably in casual conversation and mean genuinely different things. A system can be highly available and unreliable, or perfectly reliable and completely unavailable. Knowing which one you're being asked for changes what you build.
Key takeaway
Reliability is the probability that a service performs its intended functions for a specified period — it measures performance consistency under varying operating conditions. Availability asks "can I reach it?"; reliability asks "does it do the right thing when I do?"
Measuring reliability
Two metrics do most of the work: mean time between failures (MTBF) and mean time to repair (MTTR).
MTBF = (Total Elapsed Time - Sum of Downtime) / Total Number of Failures MTTR = Total Maintenance Time / Total Number of Repairs
System designers strive for a high MTBF and a low MTTR — fail rarely, and recover fast when you do.
| Metric | Question it answers | Improve it by | Direction you want |
|---|---|---|---|
| MTBF | How long between failures? | Better testing, redundancy, quality hardware, load shedding | Higher |
| MTTR | How long to recover? | Automated failover, good runbooks, fast rollback, observability | Lower |
| MTTF | How long until it dies for good? | Component quality; used for things you replace, not repair | Higher |
Reliability and availability
These are key metrics for measuring compliance with agreed service level objectives (SLOs), and they capture different things:
- Availability is driven by time loss — how much of the period the service was unreachable.
- Reliability is driven by the frequency and impact of failures — how often it misbehaves and how badly.
Together they let stakeholders assess the overall health of a service.
Mathematically, availability (A) depends on reliability (R) as one of several factors. But because R can change independently, all four combinations are real:
| Combination | Behavior | What it feels like |
|---|---|---|
| Low A, low R | Frequent failures, slow recovery | Broken. Users leave. |
| Low A, high R | Rare failures, slow recovery | Works well, then vanishes for hours. A batch system with no failover. |
| High A, low R | Frequent failures, fast recovery | Always reachable, often wrong. Retries mask it — until they don't. |
| High A, high R | Rare failures, fast recovery | The goal. |
The interesting quadrant is high A, low R. A system that is always reachable but frequently returns wrong or degraded answers scores beautifully on an uptime dashboard and is actively harmful to users — this is Chapter 1's gray failure wearing a green badge.
The distinction, stated cleanly
Interviewers ask this directly. The crisp version:
Reliability measures how well a system performs its intended operations — its functional correctness over time. We measure it with averages: mean time to failure, mean time to repair.
Availability measures the percentage of time a system accepts requests and responds to clients.
Two examples that make the gap concrete:
Example 1 — they diverge numerically. A system may be 90% available but only 80% reliable: reachable most of the time, correct less often than that.
Example 2 — they can invert completely. Treat everything inside a data center as "the system." A network failure cuts it off: no outside traffic in, no inside traffic out. Instantaneous availability is zero — no client can reach the service. Instantaneous reliability is 100% — every system inside is functioning perfectly. Nothing is broken; nothing is reachable.
Both metrics are used, in different contexts. Storage vendors quote MTTF for disks. Most online services state uptime in their SLAs — EC2 virtual machines, for instance, commit to 99.95%.
Making it actionable
Reliability improves through the same mechanisms Chapter 1 introduced, now with a metric attached:
| Technique | Moves which metric | How |
|---|---|---|
| Redundancy + failover | MTTR down | Traffic shifts to a healthy replica without human involvement |
| Health checks + outlier ejection | MTTR down | Bad nodes leave the pool before users notice |
| Canary / staged deploys | MTBF up | A bad release reaches 1% of traffic, not 100% |
| Idempotency + retries | Reliability up | Transient faults stop becoming user-visible errors |
| Load shedding + rate limits | MTBF up | Overload degrades gracefully instead of collapsing |
| Fast rollback | MTTR down | Recovery is one command, not a debugging session |
Key takeaway
At scale, failure is not an event — it is a background rate. Design assuming components fail constantly, and optimize for how fast you notice and recover rather than for a fantasy of never failing.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Uses the terms, roughly interchangeably. |
| L5 | Separates them: "availability is uptime, reliability is correctness — MTBF and MTTR are how we measure the second one." |
| Staff+ | Uses the relationship: "availability is MTBF over MTBF plus MTTR, and MTTR is the cheaper lever — I'd spend on automated failover and fast rollback before trying to eliminate failures. Also worth separating durability: we can tolerate being unreachable, we cannot tolerate losing the write." |
Next: the property that determines your MTTR long before an incident starts.