MTTR, MTBF and MTTA meaning: definitions, formulas and worked examples

The short version: MTTR is the average time it takes to fix or recover from a failure. MTBF is the average time a system runs between failures. MTTA is the average time it takes someone to acknowledge an incident. MTTR and MTTA measure how fast your support team acts. MTBF measures how reliable the system is. Always write down which "R" your MTTR means before you put it in a contract.

If you have ever opened a monthly IT support report, you have probably met these three abbreviations side by side. They look similar, they are often quoted together, and they are regularly used wrongly. This guide explains what each one means, gives the formula, works through a small example for each, and then says which ones are worth putting in a service level agreement and which belong only in a report.

For the reference definitions we used the Atlassian guide to common incident metrics, which sets out the formulas and the four meanings of MTTR. We read it on 28 October 2026 (checked 2026-10-28). The numbers in the examples below are invented for illustration. They are not Brocent results.

What do MTTR, MTBF and MTTA stand for?

All three are "mean time" figures. A mean is the total divided by the count, so each answers the question "on average, how long?" about a different stretch of an incident's life.

• MTTA, mean time to acknowledge: from the moment an alert or ticket is raised until a person starts work on it.
• MTTR, mean time to repair, recover, respond or resolve: from the start of the failure (or the start of the ticket) until the service is working again. The "R" is the problem, and the next section explains why.
• MTBF, mean time between failures: how long a repairable system runs, on average, from one failure to the next.

Think of one outage as a timeline. The fault starts, an alert fires, someone acknowledges it, someone fixes it, and then the service runs happily until the next fault. MTTA measures the first gap. MTTR measures from the fault to the fix. MTBF measures the long stretch between fixes and the next fault.

What does MTTR mean, and why are there four versions?

MTTR is the most quoted of the three and the least consistently defined. Atlassian points out that the R can stand for repair, recovery, respond or resolve, and that the four overlap but are not the same measurement. Here is how we read each one.

• Mean time to repair: the hands-on time spent fixing the fault, usually from when repair work begins to when it ends, including the testing needed until the system is fully working again. It leaves out detection and waiting time.
• Mean time to recover: the full time from the start of the failure to the point when the service is back for users. It includes detection, acknowledgement, diagnosis, the fix and any testing. This is the version a business owner cares about, because it is the length of the outage.
• Mean time to respond: the average time from the first alert to the moment the system is fully recovered, not counting any lag in the alerting system. This follows the Atlassian definition.
• Mean time to resolve: the time from the ticket being opened to being closed as resolved, including any permanent fix and follow-up. In a service desk tool, this is often what the report calls MTTR.

None of these is wrong. The mistake is comparing a number that means one thing with a number that means another. A provider who reports a 40-minute "repair" time and a customer who experienced a three-hour outage can both be telling the truth.

The practical rule is to write the definition next to the number: which timestamp starts the clock, which one stops it, and whether time spent waiting for the customer is counted.

How do you calculate MTTR? A worked example

The formula is simple:

MTTR = total time spent across all incidents ÷ number of incidents

Suppose a support team resolves five incidents in a month, and the time from ticket opened to service restored is:

1. Incident A: 45 minutes
2. Incident B: 90 minutes
3. Incident C: 30 minutes
4. Incident D: 240 minutes
5. Incident E: 15 minutes

The total is 45 + 90 + 30 + 240 + 15 = 420 minutes. Divide by five incidents and the MTTR is 84 minutes.

Now look at the same data another way. Put the five times in order: 15, 30, 45, 90, 240. The middle value, the median, is 45 minutes. Four of the five incidents were fixed in 90 minutes or less, but one slow incident (D) pulled the mean up to 84 minutes. The mean is accurate and also misleading, because no single incident actually took 84 minutes.

That is why we recommend reporting the median and the longest incident beside the mean. If you only report the mean, one bad night makes an otherwise healthy month look poor, and a handful of quick password resets can hide one failed server.

What does MTBF mean, and how is it calculated?

MTBF is a reliability measure for things that can be repaired and put back in service: a server, a firewall, a link, a line-of-business application. The formula is:

MTBF = total operating time ÷ number of failures

Worked example. A file server is monitored for 30 days, which is 720 hours. It fails three times, and the combined downtime is 6 hours.

1. Operating time = 720 − 6 = 714 hours.
2. Number of failures = 3.
3. MTBF = 714 ÷ 3 = 238 hours.

On average, the server ran for 238 hours between failures, a little under ten days.

Two cautions. First, MTBF needs a decent amount of history. Three failures in one month tells you very little about the next year. Second, MTBF is for repairable systems. For something you replace rather than repair, the equivalent figure is MTTF, mean time to failure, and Atlassian notes that MTTF is the better choice for non-repairable items.

MTBF is also an average across a fleet or a period. It does not predict when a specific device will fail. Do not read "238 hours" as a promise that the server will survive 238 hours.

What does MTTA mean, and how is it calculated?

MTTA measures responsiveness. The formula is:

MTTA = total time between alert and acknowledgement ÷ number of incidents

Worked example. Five incidents are raised, and the time until an engineer picked each one up was 4, 6, 10, 3 and 12 minutes. The total is 35 minutes, so MTTA is 35 ÷ 5 = 7 minutes.

A low MTTA says that alerts reach a person quickly and that person acts on them. A rising MTTA is an early warning that the queue is overloaded, alerts are being ignored, or the on-call routing is wrong. It does not say anything about how long the fix will take.

MTTA is close to the "first response time" you see in an SLA, but not identical. A first response target is a per-ticket promise ("every critical ticket gets a response within 15 minutes"). MTTA is the average of the actual times. A team can have a good MTTA and still miss the target on individual tickets. Our article on P1 to P4 priority levels explains how first response targets are set per priority.

MTTR vs MTBF: how do they relate?

They describe opposite sides of the same coin, and together they give you availability.

• MTBF says how often something breaks.
• MTTR (in the "recover" sense) says how long each break lasts.

Availability is the share of time the service is up:

Availability = MTBF ÷ (MTBF + MTTR)

Using the file server from before: MTBF is 238 hours. Downtime was 6 hours across 3 failures, so MTTR is 6 ÷ 3 = 2 hours. Availability is 238 ÷ (238 + 2) = 238 ÷ 240 = 0.9917, or about 99.2%. You can confirm it the other way: 714 hours up out of 720 is the same 99.2%.

This relationship shows you two ways to improve. You can make failures rarer, which raises MTBF, usually through better hardware, patching, monitoring and change control. Or you can make recovery faster, which lowers MTTR, through better runbooks, spare parts, escalation paths and automation. For a small business, the second route is often cheaper and faster to act on.

Which of these metrics belong in an SLA, and which only in a report?

Contract wording and management reporting have different jobs. Our view:

1. Per-ticket response and resolution targets belong in the SLA. They are promises you can check ticket by ticket, for example a first response time and a resolution time for each priority. Brocent publishes these on its SLA page: a critical (P1) ticket has a 15-minute first response and an 8 business hour resolution target, and the premium service window adds 24x7 cover. The what-is-an-SLA article explains how to read figures like these.
2. MTTA and MTTR belong in the monthly report. They show the trend. They are averages, so a single average is a poor basis for a penalty clause.
3. MTBF belongs in a reliability or capacity review. It matters for infrastructure: which firewall, link or server keeps failing and should be replaced.

If a contract does use an average, such as "average resolution time below four hours", define the clock start, the clock stop, the pause rules (for example, waiting for the customer), and whether severe incidents are excluded. Without those four lines the number cannot be audited.

How should you agree on the definitions before you start tracking?

Use this short checklist when setting up reporting with any provider or internal team.

1. Say which MTTR you mean: repair, recover, respond or resolve.
2. Name the start timestamp (alert raised, ticket created, or fault began) and the stop timestamp (service restored, ticket resolved, or ticket closed).
3. Decide how to treat time waiting for the customer, for a vendor, or for an approved change window.
4. Decide whether to count by incident or by ticket, and whether duplicates and false alarms are excluded.
5. Report by priority, not as one blended number, so a P4 request does not dilute a P1 outage.
6. Report the median and the slowest case next to the mean.
7. Keep the definitions in the same document as the numbers.

For how to tie these reports to the priority definitions behind them, read severity vs priority in IT incidents. When an outage is large enough to need its own process, see our guide to major incident management. For the recovery side of availability planning, see RTO vs RPO.

Where can you see Brocent's published service levels?

The response targets we commit to for each priority are public on the SLA page, and the two service window options, 8x5 and 24x7, are described there. Our managed IT support plans and per-user pricing shows the managed IT support list prices and states a 15-minute first response on critical incidents within the service window in your contract, so you can compare before you talk to anyone. If you want to discuss which service levels and reports suit your business, contact us.

Frequently asked questions

What does MTTR stand for?

MTTR stands for mean time to repair, recover, respond or resolve, depending on who is using it. All four are an average duration. Because they start and stop the clock at different moments, always check which one a report is quoting.

What is the difference between MTTR and MTBF?

MTTR measures how long a failure lasts on average. MTBF measures how long a system runs, on average, between failures. MTTR is about recovery speed, and MTBF is about reliability. Together they give availability: MTBF divided by (MTBF plus MTTR).

What does MTTA mean?

MTTA is mean time to acknowledge: the average time from an alert or ticket being raised to someone starting work on it. It is a measure of responsiveness, not of how long the fix takes.

Is a lower MTTR always better?

Usually, but not automatically. A lower MTTR is good if the fixes are real. Teams under pressure can lower MTTR by closing tickets early or applying temporary workarounds and not fixing the cause, then see the same incident return. Read MTTR together with the number of repeat incidents.

What is a good MTTR?

There is no single good figure, because it depends on the system, the priority and the service window. A critical outage should be measured in minutes or hours, and a low-priority request in days. Set targets per priority and compare against your own history, not a generic benchmark.

Should an SLA include MTTR?

Per-ticket resolution targets belong in an SLA. An average MTTR works better as a reporting metric, because averages hide outliers. If an average must go in the contract, define the clock rules precisely.

How is MTBF different from MTTF?

MTBF is for systems you repair and return to service. MTTF, mean time to failure, is for items you replace when they fail. Both are averages of working time, but MTTF counts only up to the first failure.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.