MTBF, MTTR and availability: formulas and a worked example

The formulas

• MTBF = total uptime ÷ number of failures
• MTTR = total downtime ÷ number of failures
• MTTA = average time from alert to acknowledgement
• Availability = MTBF ÷ (MTBF + MTTR)

The availability formula looks at one average cycle: the system runs for MTBF hours, fails, and is down for MTTR hours. The share of the cycle it is running is the availability. It is the same as total uptime ÷ total time, which makes a handy check.

Working through the incident log

The third quarter of 2026 has 92 days, or 2,208 hours. The web application failed six times and was down between 0.5 and 3.25 hours each time, 9.0 hours in total. That leaves 2,199 hours of uptime.

• MTBF = 2,199 ÷ 6 = 366.5 hours, about 15 days between failures.
• MTTR = 9.0 ÷ 6 = 1.50 hours.
• Availability = 366.5 ÷ (366.5 + 1.5) = 99.59%, exactly the 2,199 ÷ 2,208 of the check row.
• MTTA = the average of the six acknowledgement times = 10.5 minutes.

If your log holds timestamps instead of durations, remember that Excel stores date-times as days. With the start of the outage in B2 and the restore time in C2, =(C2-B2)*24 gives the hours down and =(C2-B2)*24*60 the minutes.

Worked example: one quarter's incident log

The six incidents and the hours in the quarter are the yellow inputs. MTTA, MTTR, MTBF, availability and the nines table are formulas.

Worked example: one quarter's incident log

	A	B	C
1	Incident, Q3 2026	Minutes to acknowledge	Hours to restore
2	12 Jul	4	1.50
3	29 Jul	12	0.75
4	14 Aug	7	3.25
5	2 Sep	25	0.50
6	17 Sep	6	2.00
7	28 Sep	9	1.00
8
9	Hours in the quarter (92 days × 24)		2,208
10	Number of failures		6
11	Total downtime (hours)		9.00
12	Uptime (hours)		2,199.00
13	MTTA (minutes)		10.5
14	MTTR (hours)		1.50
15	MTBF (hours)		366.5
16	Availability = MTBF ÷ (MTBF + MTTR)		99.59%
17	Check: uptime ÷ hours in the quarter		99.59%
18
19	Availability target	Downtime per year (hours)	Per 30-day month (minutes)
20	99.00%	87.60	432.0
21	99.50%	43.80	216.0
22	99.90%	8.76	43.2
23	99.95%	4.38	21.6
24	99.99%	0.88	4.3

The incident log is fictional. Downtime per year uses 365 days and per month 30 days. Check your SLA for how it treats planned maintenance.

Uptime, not calendar time, for MTBF

MTBF divides the uptime by the number of failures, because a system cannot fail while it is already down. Dividing the whole quarter, 2,208 ÷ 6 = 368 hours, gives the average time from the start of one failure to the start of the next. ITIL calls that the mean time between service incidents (MTBSI), which equals MTBF + MTTR. The difference is small here but grows with long outages.

For items that are replaced rather than repaired, such as a disk or a fan, the matching measure is MTTF, the mean time to failure. And an MTBF is a fleet average, not a lifetime: a disk rated at 1,000,000 hours will not last 114 years, it means that a large group of such disks sees about one failure per million operating hours in its service life.

What the R in MTTR means

MTTR is used for four different things, and teams that compare numbers often discover they measured different ones:

• Mean time to repair: the hands-on time spent fixing the fault.
• Mean time to recovery or restore: from the start of the outage until the service works again for users. ITIL 4 calls it MTRS, mean time to restore service.
• Mean time to resolve: until the incident is fully closed, including the root-cause fix.
• Mean time to respond: until someone starts working on it, close to MTTA.

For availability, use the time to restore, measured from the moment the outage began. If you measure from detection, the minutes before anyone noticed are missing, which is why many teams also track MTTD, the mean time to detect.

The nines: allowed downtime per year and month

Allowed downtime = (1 − availability target) × time in the period

Rows 19 to 24 of the example show the usual targets. 99.9%, three nines, allows 8.76 hours a year or 43.2 minutes in a 30-day month. 99.99% allows 0.88 hours, about 53 minutes, a year and 4.3 minutes a month. Five nines, 99.999%, leave about 5.3 minutes a year. Every extra nine cuts the allowed downtime by a factor of ten and usually costs much more in redundancy and on-call staff.

Back to the example: at 99.9%, the quarter allows 2,208 × 0.1% = 2.2 hours. The application was down for 9.0 hours. With six failures a quarter, it would need an MTTR below 2.2 ÷ 6 = 0.37 hours, about 22 minutes, to meet three nines.

MTBF or MTTR: which lever to pull?

Halving the number of failures doubles the MTBF and cuts the downtime to 4.5 hours, for an availability of 99.80%. Halving the MTTR to 0.75 hours gives exactly the same 4.5 hours and 99.80%. On paper the two levers are equal, but faster recovery is often the cheaper one: better alerts, runbooks, automated rollback and a clear on-call rota.

Availability also treats every hour the same. An hour down at peak time costs more than an hour at night, so to put a price on outages, combine their frequency and cost per incident as in the annual loss expectancy formula.

Common mistakes

• Dividing the whole period by the failures for MTBF. Subtract the downtime first: MTBF uses uptime only.
• Measuring MTTR from the acknowledgement. Downtime starts when the outage starts, not when someone picks up the ticket.
• Mixing MTTR definitions. Repair, restore, resolve and respond times differ. Write down which one you report.
• Treating planned maintenance inconsistently. Many SLAs exclude announced maintenance windows. Decide once and apply it to every month.
• Averaging the availability of services that depend on each other. Two services in a chain, each at 99.9%, give 99.9% × 99.9% = 99.8% together.
• Reading MTBF as a lifetime. It is an average rate across many units or many failures, not a promise for one device.