Reliability: MTBF, MTTR, and Why It Isn't Availability
In one line: 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.
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 |
MTTR is the cheaper lever, and it's under-used
Recall from the previous lesson that Availability = MTBF / (MTBF + MTTR). Both terms move the result, but they don't cost the same. Doubling MTBF means eliminating half of all failures — expensive, slow, and eventually you hit diminishing returns against hardware and the physical world. Halving MTTR means better automation, faster rollback, and clearer dashboards — usually cheaper, and entirely within your control.
At scale, failure is constant. The system that recovers in 30 seconds beats the system that fails half as often and takes an hour.
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 that building block'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%.
Don't forget the third word: durability
People conflate three concepts, not two. Availability = can I reach it. Reliability = does it behave correctly. Durability = once written, is the data still there.
They fail independently. S3 famously targets eleven nines of durability while offering far fewer nines of availability — your object is essentially never lost, but the service may occasionally be unreachable. That is a deliberate, sane trade: an unreachable object can be fetched in a minute; a lost one is gone forever. Naming durability separately in an interview is a strong signal.
Making it actionable
Reliability improves through the same mechanisms that building block 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.