Reliability is usually framed as a question of failure rate: how often does the system go down? But failure rate is only half the picture. The other half is recovery time: when the system does go down, how long does it take to come back? A system that fails once a month but takes twelve hours to recover has accumulated more total downtime than one that fails four times a month but recovers in thirty minutes. The failure rate looks better in the first case; the outcome is worse.

This matters because most reliability work focuses on preventing failures rather than accelerating recovery. Prevention is appealing — it keeps incidents off the board entirely. But prevention has diminishing returns. The closer you get to zero failures, the more expensive each additional unit of prevention becomes. At some point, investing in recovery speed returns more total reliability per unit of effort than investing in further prevention.

The practical implication is that recovery paths deserve the same engineering attention as failure prevention. This means knowing, for each class of failure, what the recovery procedure is and how long it takes. It means having that procedure documented and tested before an incident, not derived on the fly during one. It means identifying the steps that add the most latency to recovery — approvals that require someone to be reachable at 3 AM, runbooks that are out of date and lead the responder through three wrong paths before the right one, deployments that take forty minutes to complete — and removing them or making them faster.

It also means measuring recovery time explicitly, not just failure rate. Mean time to recovery is a real metric, and it should be tracked alongside failure count. When you track both, you get a clearer picture of where the reliability investment is actually needed. A system with a high failure rate but a fast recovery path might be lower priority than a system with a low failure rate but a slow, painful recovery. The failure rate draws your attention; the recovery time determines the cost.

The hardest part of this framing is that slow recovery often looks like a people problem rather than a systems problem. The runbook is out of date because nobody updated it. The approval gate takes hours because the right person wasn’t reachable. The deployment is slow because the pipeline was never optimized. These feel like organizational issues, and they are — but they’re also engineering problems with engineering solutions. An automated rollback removes the approval gate. A tested runbook with a recent date removes the uncertainty. A faster deployment pipeline removes the latency. Recovery time is a design choice, and it can be engineered down the same way failure rate can.