MTTR & MTBF Calculator

Measure repair speed and failure cadence: MTTR from total repair time and, optionally, availability from a provided MTBF β€” framed around incidents, not SLO error budgets.

Input data

Additional options (optional)

In this calculator, MTBF is treated as an input (average time between failures), not automatically derived from a fixed calendar window.

Results

Enter data and click Calculate.

MTTR, MTBF, MTTA, and MTTD

MTTR (Mean Time To Repair) is the average time needed to restore service after a failure. MTBF (Mean Time Between Failures) is the average uptime between failures β€” here you supply it as an input (from history or an estimate), not as a value derived from a fixed calendar window. In practice, SRE teams often also break an incident down into MTTD (time to detect) and MTTA (time to acknowledge) β€” the MTTR this calculator computes covers the full repair duration, however it was measured.

Formulas

MTTR = total repair time Γ· number of failures. When you also provide MTBF, the calculator computes estimated availability: Availability = MTBF Γ· (MTBF + MTTR) β€” the standard steady-state availability model used in reliability analysis.

Availability targets vs failure cadence

Compare availability estimated from MTBF/(MTBF+MTTR) with common β€œnines” targets. Compact table below β€” for a fuller SLO downtime breakdown, see the Error budget calculator.

Availability targetDowntime / year (approx.)
99%~3.65 days
99.9%~8.76 hours
99.99%~52.6 minutes

How to reduce MTTR

  • Runbooks and automation for common repair actions (restart, rollback, failover) cut repair time more than faster detection alone.
  • Good dashboards and alerts with concrete context (not just "something is wrong") shorten diagnosis time β€” the largest chunk of MTTR is often spent just figuring out what broke.
  • Blameless post-mortems and tracked remediation items prevent the same long repair from recurring.

MTTR vs MTBF β€” what to fix first

Availability depends on both values, but improving them has different costs. Increasing MTBF (fewer failures) often requires architectural changes (redundancy, better testing) and is expensive. Reducing MTTR (faster repair) is usually cheaper and quicker to deploy β€” which is why many SRE teams invest in incident-response automation first, and fundamental reliability work second.

Examples

  • 10 hours of total repair time across 5 failures β†’ MTTR = 2 hours.
  • MTTR = 2h, MTBF = 100h β†’ availability β‰ˆ 98.04%.
  • Same MTBF = 100h, but MTTR cut to 0.5h β†’ availability β‰ˆ 99.50% β€” showing how much impact shortening repair time alone can have.

FAQ β€” MTTR and MTBF

How is MTTR different from MTTA and MTTD?
MTTD is time to detect a failure, MTTA is time for the team to acknowledge it, and MTTR is time to full repair. This calculator computes MTTR from total repair time β€” you can measure it from detection or from acknowledgement, depending on your team’s convention.
What exactly counts as "repair time"?
Most commonly, the time from starting remediation to fully restoring service. Some teams count from detection (including diagnosis), others from acknowledgement β€” what matters is being consistent in how you report it.
Where do I get MTBF for a new system with no failure history?
You can estimate it from component specs (vendors publish hardware MTBF), from similar systems in your organization, or start without MTBF and fill it in once you have production data.
Does lower MTTR always mean a more reliable system?
No β€” MTTR only tells you how fast you fix failures, not how often they happen. A system with frequent but quickly-fixed failures can have a lower MTTR than a stable system with rare, long repairs, yet still worse overall availability.
How does MTTR relate to error budgets?
More frequent or longer repairs burn through the error budget faster. Reducing MTTR is one of the most effective ways to stay within an SLO with the same number of failures.
Can MTTR be zero?
In practice, no β€” even an automatic failover has a non-zero switchover time. Very low MTTR (seconds) is achievable with well-designed automation, but rarely exactly zero.
What is a "good" MTTR for a production service?
It depends on your SLO and business scale β€” critical services aim for minutes, less critical ones for hours. The trend matters more than the absolute value: is MTTR going down over time?
Does this availability formula assume anything specific about failure distribution?
It is the standard steady-state availability model from reliability theory β€” it assumes averaged, repeating operate/repair cycles, not a single catastrophic incident.