MTTR, MTBF, and MTTA Explained

What this guide covers

MTTR, MTBF, and MTTA are the core reliability metrics teams use to talk about incidents numerically. This guide defines each one precisely, shows the formulas and how they connect to availability, and explains how to use them to drive real improvement instead of producing a nicer-looking monthly average.

• MTTA measures how fast alerts are acknowledged.
• MTTR measures how fast service is restored.
• Outliers and repeat causes teach more than the average.

The definitions, precisely

These terms get muddled, so define them explicitly for your team:

• MTTA (Mean Time To Acknowledge) — average time from alert firing to a human acknowledging it. Measures alerting and on-call responsiveness.
• MTTR (Mean Time To Recovery) — average time from incident start to service restored. Note MTTR is ambiguous in the wild (Recovery, Repair, Respond, Resolve); pick one definition and document it.
• MTBF (Mean Time Between Failures) — average operational time between failures for a repairable system. Measures how often things break.

The formulas

MTBF = total operational time ÷ number of failures. MTTR = total downtime ÷ number of incidents. MTTA = total acknowledgment time ÷ number of alerts. These connect to availability: Availability ≈ MTBF ÷ (MTBF + MTTR). In other words, you improve availability either by failing less often (higher MTBF) or by recovering faster (lower MTTR) — and for most teams, recovering faster is the cheaper lever to pull.

Using them without gaming them

Track the distribution, not just the mean. Report the median and the worst-case (p95 or max) alongside the average, because the tail is where customer pain lives. Segment by cause to find patterns — if three of this quarter's incidents share a root cause, that is worth more than a decimal improvement in average MTTR. And treat MTTA separately: a great MTTR built on a terrible MTTA means you recover fast once someone finally notices.

How Sandglass supports the practice

These metrics need accurate incident timestamps to mean anything. Sandglass records when a check failed (incident start) and when it recovered, and when alerts fired — the raw data behind MTTA and MTTR — so your numbers come from measured events rather than reconstructed guesses.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

Averages hide bad incidents. A month with nineteen two-minute blips and one six-hour outage can show a flattering MTTR while the six-hour outage is the only thing customers remember. Look at the worst incidents and repeated causes before celebrating a lower average — and never reward a team for a metric they can improve by simply closing incidents faster on paper.