Enter your incident count, repair time and running time below to get MTTR, MTBF, availability and expected downtime per year. The formulas, a worked example and the traps that make these numbers misleading are underneath.
MTTR & MTBF calculator
Use one consistent period — a month, a quarter, a year — for all three inputs. Everything recalculates as you type.
Availability here is the modelled figure from MTBF and MTTR. It answers “what should this estate deliver on average”, which is not the same question as “what did it actually deliver” — see the note further down.
The Formulas
The two metrics measure opposite halves of the same cycle. MTBF is the length of the working stretches; MTTR is the length of the repair stretches. Availability is simply how those two compare. MTTR vs MTBF vs MTTF covers which one to work on when they disagree.
A Worked Example
Take a switch over one year. It ran for 8,640 hours, failed 12 times, and the twelve repairs took 48 hours in total.
| Step | Arithmetic | Result |
|---|---|---|
| MTTR | 48 hours ÷ 12 incidents | 4 hours |
| MTBF | 8,640 hours ÷ 12 failures | 720 hours (about 30 days) |
| Availability | 720 ÷ (720 + 4) | 99.448% |
| Downtime / year | (1 − 0.99448) × 8,760 hours | about 48 hours |
Getting the Inputs Right
The arithmetic is trivial. Nearly every wrong MTTR figure comes from the inputs, not the division.
- Use one period for all three numbers. Incidents from a quarter divided by repair hours from a month produces a figure that means nothing, and it is the most common mistake.
- Decide which two timestamps MTTR spans, then keep it. Creation to resolution, detection to resolution, and first response to resolution all get called MTTR and give different answers. Any of them is defensible; changing it mid-year is not. The four metrics that share the abbreviation sets out the differences.
- Running time excludes repair time. If you feed in total elapsed time rather than uptime, MTBF comes out slightly high. Over a year with little downtime the error is small; on a system that is down often, it is not.
- Below about twenty incidents, quote the median too. A single fourteen-hour outage drags a small sample's mean somewhere no typical incident lives.
What Availability Actually Promises
| Availability | Downtime / year | Downtime / month |
|---|---|---|
| 99% | 3d 15h | 7h 18m |
| 99.5% | 1d 19h | 3h 39m |
| 99.9% | 8h 46m | 43m |
| 99.95% | 4h 23m | 21m |
| 99.99% | 53m | 4m |
How InfraCue Reports These
If you would rather not maintain this in a spreadsheet, InfraCue reports both metrics from your ticket data directly:
- MTTR. The tile reads MTTR · 30 Days and shows mean wall-clock time from ticket creation to resolution, on a rolling 30 days against the previous 30, with the ticket count behind the mean. Workspace-wide on the admin dashboard, per-engineer on the infra dashboard.
- MTBF. Mean time between one ticket being raised and the next, over exactly the tickets MTTR measures — same eligibility, same window, same comparison period, so the two cards describe one estate rather than two.
- Measured device availability. Network Pulse polls watched devices and reports availability as successful checks divided by total checks, per device, alongside the outages behind it — the measured figure rather than the modelled one.
InfraCue is free for 30 days — tickets, SLA timers, MTTR, MTBF and per-device availability from your own incidents. No credit card, nothing to cancel.
Start a free 30-day trialCommon Questions
What is a good MTTR?
There is no universal number, because it depends entirely on which two timestamps you measure and what you support. The useful benchmark is your own trend: MTTR falling quarter on quarter with a stable incident count means your response is genuinely improving. A cross-industry figure quoted without its definition is close to meaningless.
How do I calculate MTTR in a spreadsheet?
Add a column for resolution timestamp minus creation timestamp, take the average of that column, and format the result as elapsed time rather than clock time — that last step is where most spreadsheets go wrong, showing 4:00 as four o'clock rather than four hours. Take the median of the same column while you are there.
Does MTTR include time waiting on the requester?
It does unless you deliberately subtract it. Wall-clock MTTR answers “how long was this open”, which is the business-facing question. If you want “how fast does the team work”, you need the SLA clock, which pauses on waiting states. Reading both together shows how much of your MTTR is your team and how much is everyone else.
Can I calculate MTBF without knowing running time?
You can approximate it from incident timestamps alone: sort the failures by date and average the gaps between consecutive ones. That is the interval between failures rather than operating hours divided by failures, so it quietly includes repair time, but on systems with short repairs the two land close together.
Why does my availability look better than it feels?
Usually because the model is being asked a question it cannot answer. A system with 99.9% availability delivered as one 8-hour outage during month-end feels nothing like the same figure delivered as 43 minutes a month. Averages hide distribution, which is why the outage list matters as much as the percentage. See what an SLA breach actually is for how those targets get set and missed.