MTTR for software teams: meaning, formula, and examples

MTTR stands for mean time to resolution: the average time your team takes to resolve an incident.

Say your team had two incidents last month. One took 40 minutes to resolve, the other took 20. Your MTTR was 30 minutes.

Easy enough to calculate. Though before you compare that number with another team's, you'll want to check what they're measuring. They might start counting when an alert fires, while you're counting from when customers first saw errors.

Let's go through an example, then look at how to use it to improve your incident response.

What does MTTR mean?

Depending on where you work, you'll hear MTTR used to mean a few different things:

• Mean time to resolution: how long it takes to resolve an incident.
• Mean time to recovery: how long it takes to get the service working again.
• Mean time to repair: how long it takes to fix a failed component, often used when discussing hardware.
• Mean time to respond: how long it takes someone to respond after an alert. You may also see MTTA, or mean time to acknowledge, for the time until someone acknowledges it.

For this article, we're measuring from when customers first experience the problem until the team verifies the fix and resolves the incident.

Your organisation may use a different definition. Write down the start and end events alongside the metric so whoever reads it knows what you've counted.

MTTR formula: how to calculate mean time to resolution

Choose a reporting period, add up the time taken to resolve each incident in it, then divide by the number of resolved incidents:

Mean time to resolution = Sum of incident resolution durations / Number of resolved incidents
Incident resolution duration = Resolution timestamp - Incident start timestamp

Using our two incidents, that's (40 + 20) / 2 = 30 minutes.

Count incidents rather than alerts. One outage can trigger dozens of alerts, but it's still one incident.

Here's what one of those incidents might look like. All times are in the same timezone:

Event	Time	Minutes since impact
Customers begin seeing errors	09:00	0
Monitoring detects failures	09:05	5
On-call acknowledges the alert	09:08	8
Rollback restores customer access	09:22	22
Team verifies the fix and resolves the incident	09:40	40

It took five minutes to detect the problem and another three for someone to acknowledge the alert. Customers could use the service again after 22 minutes. The team then spent 18 minutes checking the fix before resolving the incident.

So the time to recovery was 22 minutes, and the time to resolution was 40 minutes. If your team closes incidents as soon as the service is restored, those timestamps may be the same. That's fine, as long as it's clear what you're reporting.

Note that starting the clock when monitoring detected the problem would leave out five minutes of customer impact. Sometimes you won't know exactly when an incident started; record your best estimate and mark it as such.

You should also decide which incidents you're including. For example, does a failure affecting one customer count? Is planned maintenance excluded? Use the same rules each month, and include the period and incident count with the result.

What's a good MTTR for a software team?

It depends on what broke. Customers being unable to pay for an order is a different problem from an internal report arriving late.

Start with your own incident history. Group incidents by service and severity so you can make a useful comparison over time. Agree on targets based on how long customers can tolerate the interruption and what your team needs to improve to get there.

Keep the individual durations visible too. If nine incidents took one minute each and the tenth took 91 minutes, your MTTR would be ten minutes. You'd probably still want to spend some time reviewing that 91-minute outage.

How to reduce MTTR

During your post-incident review, go through the timeline with the people who handled the incident. Ask where they got stuck and what they were waiting for.

The timestamps give you a place to start. The people involved can explain what happened between them.

Detect the problem earlier

If customers were seeing errors long before your team knew, check whether you're monitoring the part of the service that failed.

For example, your homepage might return a successful response while customers can't log in. You'll need a check that exercises the login flow to catch that problem. Uptime monitoring can help detect failures from outside your infrastructure, but the checks still need to cover what your customers use.

Make sure the alert reaches someone

Check who received the alert, whether they were on call, and what happened when they didn't acknowledge it.

If the alert went to an unmonitored channel, fix the routing and escalation. If it was ignored because the channel gets hundreds of unhelpful alerts, you'll need to work on alert fatigue too.

Document the steps that got the service working again

If someone spent 20 minutes finding the person who knew how to roll back a deployment, that's a good starting point for a runbook.

Write down when to use the procedure, the steps to follow, and how to check whether it worked. Have someone else try it in a test environment before their next on-call shift.

Explain how to verify the fix

In our example, the team spent 18 minutes checking the service after the rollback. That might have been necessary, or they might have been unsure what to check.

Your runbook should explain which metrics to watch and which customer actions to test. Don't leave someone guessing whether it's okay to close the incident.

If they're also answering customer questions, have another team member handle incident updates. A status page gives people somewhere to check progress while the on-call engineer works on the problem.

MTTR vs MTBF and other incident metrics

MTBF stands for mean time between failures. It measures the average operating time between failures, while MTTR measures how long it takes to repair, recover, or resolve them, depending on your definition.

You could resolve every incident in five minutes and still have a service that breaks every day. Your MTTR would look good, but your customers would still be dealing with frequent interruptions.

Keep track of how often incidents happen alongside how long they last. Time to detect and time to acknowledge can help explain changes in MTTR, particularly if you've recently changed your monitoring or on-call arrangements.

After a few incidents, go back to the changes you made in your reviews. Did the new check catch the failure? Could the next person follow the rollback instructions? That's how you'll find out whether the work helped.