MTTR, or mean time to resolution, is the average time it takes to resolve an incident, measured from the moment it's detected to the moment service is restored. It's one of the clearest measures of how effectively a service desk can identify, investigate and recover from problems.
If you work on an MSP service desk, you probably already know what your MTTR is doing. The harder question is why it's doing it. Because if MTTR is climbing, the instinctive explanation is often that the team needs to be working faster. In reality, your engineers may not have become any slower – it might just be that the environment around them has become harder to work in.
More clients. More devices. More cloud services. More monitoring tools. More alerts. More places to look when something goes wrong. The result is a service desk where the difficult bit isn't necessarily fixing the problem – it's finding the problem in the first place.
What MTTR actually measures, and what it doesn't
MTTR is widely used as shorthand for mean time to repair, mean time to resolve, mean time to respond or mean time to recover. These terms are sometimes used interchangeably, but they're not necessarily measuring the same thing.
If one service desk measures from the first alert until the incident is completely resolved, while another measures from ticket creation until an engineer begins working on it, their MTTR figures can't meaningfully be compared. So, before worrying about whether your number is good or bad, make sure you know exactly what you mean by MTTR and what points in the incident lifecycle it's measuring.
How to calculate MTTR
For a straightforward resolution metric, the formula is:
MTTR = total resolution time ÷ number of incidents
For example, if five incidents take a combined 10 hours to resolve, the MTTR is two hours.
MTTR vs MTBF: what is the difference?
These two metrics are often confused, but they're two different things.
Mean time between failures, or MTBF, measures reliability: how long systems operate between failures.
Mean time to repair or resolve, or MTTR, measures recovery: how long it takes to restore service once something has gone wrong.
A system can therefore have a good MTBF but a poor MTTR, or vice versa. Improving reliability reduces how often you have to deal with incidents. Improving MTTR makes the incidents you do have easier and faster to resolve.
Why is MTTR rising?
There are plenty of reasons an individual incident can take longer than expected, but across a busy MSP service desk, three problems increasingly compound one another: alert volume, alert fatigue and tool switching.
Alert volume
Modern IT estates generate a huge amount of telemetry. That's useful up to a point; monitoring more systems and collecting more data should give an MSP better visibility into what's happening across its clients. But more alerts don't automatically mean more useful information.
As estates grow, monitoring tools multiply. Each one has its own view of what's happening and its own definition of what deserves an alert. The result can be hundreds of notifications generated by a single underlying issue.
For example, say a server goes offline. One tool reports the outage. Another reports failed checks. A third reports an application error. Users start generating tickets. Dependent services begin complaining. Suddenly, the service desk has a queue full of apparent problems when there may actually only be one problem underneath them all. Volume isn't signal.
Alert fatigue
If engineers repeatedly open notifications that turn out to be low priority, expected behaviour or symptoms of something else, they naturally become less responsive to the next alert. That's what we call alert fatigue. If a monitoring system produces a large stream of low-value alerts, slower triage is the predictable result – and it's not the engineer's fault.
The cost of that noise isn't limited to the time spent closing unnecessary alerts. A genuinely important incident could now be competing for attention with everything else in the queue. A critical problem doesn't become less critical because there are 50 other notifications beside it, but on a busy service desk, it can become harder to identify.
Tool switching
An incident arrives, so you open the ticketing system. Then the monitoring platform. Then the network monitoring tool. Then the endpoint management system. Then perhaps a cloud console or another client-specific application. Each system may contain a useful part of the picture, but the engineer has to assemble that picture manually.
Every context switch costs minutes, and an investigation that starts with a new login has already lost. More importantly, it interrupts the investigation and creates another opportunity to miss something. It's not just that there are five browser tabs open. There may be five different tools, across dozens or hundreds of client environments, each with different configurations and different sources of information.
How to reduce MTTR: what actually works
We'd recommend focusing on four practical areas.
Correlation: turn many symptoms into one incident
If multiple alerts are symptoms of the same underlying problem, the service desk shouldn't have to treat them as completely separate events. Good correlation connects related signals so that engineers can investigate the underlying issue rather than working through a queue of symptoms.
Prioritisation: deal with what matters
The loudest alert isn't necessarily the most important one. A service desk needs to understand business impact as well as technical severity. An issue affecting a critical system for a major client may deserve attention ahead of a technically similar event affecting a less critical service. Prioritising by live business impact – context-aware prioritisation – can help engineers focus their attention where it matters most, rather than simply working through whichever notification arrived first.
One view: stop making the engineer assemble the picture
A genuine single pane of glass is valuable because it reduces the number of places an engineer needs to look to understand what's happening. For an MSP, that means being able to see multiple client estates without losing the separation between them – while still giving engineers enough context to investigate an incident.
Prediction: the fastest incident is the one that never opens
If you can identify an emerging problem before it becomes an outage, you avoid the incident altogether. Monitoring is much more useful when it moves beyond telling you when something's already failed. Patterns in system behaviour can provide indications that something is heading in the wrong direction. Acting on those signals before they become a service-affecting incident can remove an entire category of work from the service desk.
What good looks like on an MSP service desk
For an MSP, reducing MTTR has another complication: you're not managing one environment, you're managing many. A useful service desk view therefore needs to preserve multi-tenancy. Engineers need to know which client an issue belongs to, while managers need visibility across the wider estate.
A practical setup might include a single alert queue across clients, with the appropriate context attached to each issue. It should be possible to investigate an incident without constantly jumping between client-specific dashboards, while still keeping each client's environment properly separated. You'll also need enough retained history to understand whether last month was actually better.
There's a natural temptation to think of tool consolidation as a cost-saving exercise, but for a service desk, it's often more fundamental than that. As an MSP grows, the number of clients, systems and alerts tends to grow with it. If the way engineers investigate incidents doesn't evolve at the same time, more of their working day can disappear into triage, switching systems and working out which alert is most urgent. That can push MTTR upwards even when the engineers themselves are doing everything right.
The answer isn't necessarily to remove every monitoring tool or replace every system – it's to make the information they produce more useful. That means correlating related alerts, prioritising incidents by their real impact, giving engineers a coherent view of the estate and identifying potential failures before they become incidents.
Ultimately, a good service desk is one where the right alert reaches the right engineer with enough context to resolve it efficiently. That's what LiveTrace is built around: bringing the signals, context and business impact together so that an MSP service desk can spend less time working out what's happening and more time resolving problems. Or even preventing them in the first place.
Frequently Asked Questions
What does MTTR stand for?
MTTR can refer to mean time to repair, mean time to resolve, mean time to respond or mean time to recover, depending on the organisation and context. For service desks, it's commonly used to describe the average time taken to resolve an incident and restore service.
How is MTTR calculated?
MTTR is calculated by dividing the total time taken to resolve incidents by the number of incidents over the period being measured. For example, if five incidents take a combined 10 hours to resolve, the MTTR is two hours.
What is a good MTTR?
There's no single MTTR that every service desk should aim for. A reasonable figure depends on the services being supported, the severity of incidents and the expectations agreed with customers. Comparing one overall benchmark across an entire MSP estate can therefore be misleading.
What is the difference between MTTR and MTBF?
MTBF, or mean time between failures, measures how long a system operates between failures, and is therefore primarily a measure of reliability. MTTR measures how long it takes to recover from a failure. One measures the frequency of failures, while the other measures the speed of recovery.
How can an MSP reduce MTTR?
Focus on four areas: correlating related alerts so that many symptoms become one incident, prioritising by live business impact rather than technical severity alone, giving engineers a single view across client estates so they are not assembling the picture manually, and identifying emerging problems before they become outages. Together these reduce the time spent finding the problem, which is often where MTTR is actually lost.
Why is our MTTR getting worse?
Rising MTTR can have many causes, but increasing alert volume, alert fatigue and switching between multiple monitoring and management tools can all make incident investigation slower. If engineers have to spend more time identifying the important signal and assembling information before they can act, resolution times can increase even when the underlying engineering work hasn't become more difficult.