Mean Time To Resolution: How To Calculate And Reduce MTTR

Mean time to resolution (MTTR) is the average time your helpdesk takes to fix a ticket, from the moment it's logged until the user confirms the fix. Add up the resolution time of the tickets resolved in a period, then divide by the number of tickets.

The math is one division. The hard part is deciding which hours count. This guide is for a one-to-five-person IT team or MSP, from the team behind SherpaDesk, a helpdesk and PSA (professional services automation) a small IT team can run alone.

What Is Mean Time To Resolution?

In ITIL's glossary, resolution means repairing the root cause or putting a workaround in place. So a workaround that gets the user working counts as resolved.

Resolution time is one of the speed numbers in our guide to helpdesk metrics, which also covers the median, the 90th percentile, and reopen rate.

The counting policy this guide uses

Which hours MTTR leaves out is a choice, so write yours down. Ours: the clock starts when the ticket is logged and stops at verified resolution, when the user confirms the fix.

Time spent waiting for that confirmation is a user wait, so it comes out with the others. Closing the ticket later, for billing or tidying, is an administrative step and doesn't move the number.

For this guide's MTTR, exclude documented time waiting on the user and time the ticket sat closed. Keep vendor waits.

What The R In MTTR Means

MTTR is four different metrics that share one acronym. As one r/msp member asked about service levels: "Is it triage? First response? Time until a tech is engaged and working on the issue? Time to resolution?" The same question applies to the R.

ITIL's glossary keeps the first two apart. Repair time leaves out the time to recover or restore, and the glossary calls using it for mean time to restore service incorrect. NIST defines mean time to recovery as the average time it takes to recover from a product or system failure. In ITIL incident management, response time runs until someone answers the call or starts diagnosis.

DORA's software delivery research has replaced MTTR with failed deployment recovery time: how long recovery takes after a failed production deployment. A helpdesk wants the last row, so spell it out in your report.

Why MTTR Matters On A Small Team

A slow resolution can leave someone blocked for longer. For internal IT, that's an employee or a classroom waiting. For an MSP, it's a client deciding whether your support is worth the contract.

On a team of three, a rising MTTR usually means more hard tickets, more tickets than people, or waits you could remove. Each needs a different fix.

One r/ITManagers member put the warning plainly: "slow ticket resolution might be down to any number of factors. Poor tech performance, yes, but also how quickly the end user responds" and what they send back. The same member added: "The tech's idea of a resolution may look very different from the end user's."

That's why the stop point matters. A ticket closed before the user confirms the fix flatters MTTR while the user is still stuck.

One r/msp member's shop will "never promise resolution time (it could be not on us, like power or ISP is out or their out of warranty workstation died)." If you share that view, keep MTTR as an internal number and put response times in client agreements.

How To Calculate MTTR

The formula: MTTR = total counted hours ÷ number of tickets resolved. In the worked example below, 20 counted hours ÷ 5 tickets = 4.0 business hours. Counted hours run from logged to verified resolution on the priority's calendar, minus documented user waits and closed gaps.

For each ticket, record the ID, priority, the logged and verified-resolution timestamps, each reopen span, and the start and end of every user wait. Count a user wait only inside the priority's coverage hours, so a weekend inside a wait isn't subtracted twice.

To calculate MTTR for a month, work one priority at a time:

1. Pick the period and the tickets

   Take every ticket at one priority whose final verified resolution falls in the period, including older tickets. Keep service requests apart: a new hire's laptop, booked for a start date, isn't a fault.

2. Measure each ticket on its clock

   Count the hours from logged to verified resolution on that priority's calendar: business hours for a P3, all hours for a P1 you cover at 2 a.m.

3. Take out the user waits

   Subtract the documented hours the ticket waited on the user, as the table below sets out.

4. Handle the reopens

   If a ticket reopens for the same problem, add all its open spans and exclude the closed gaps. Assign the ticket once, by its final verified-resolution date. If it reopens after you've published that period, issue a labeled correction and keep the original report as a snapshot.

5. Divide

   Divide the counted hours by the tickets resolved. Write the unit next to the number: "4.0 business hours, P2." With no resolved tickets, report MTTR as unavailable, not zero.

What to leave out of the clock

Our SLA management guide covers when the SLA clock may pause. This guide's MTTR policy keeps vendor waits in.

Some practitioners pause for vendors too. One r/msp member puts the timer on "sla hold" when they "await approval, decision, mail from client/thirdparty". This guide keeps vendor hours in, because the user is still stuck and the escalation is yours.

Worked Example: P2 Helpdesk Tickets

Say you run a three-technician MSP with an 8 a.m. to 5 p.m. clock for P2 tickets. Six P2 tickets came in one week.

Ticket D's 9.5 business hours run from the first log to the final confirmed fix, including seven business hours while the ticket was closed. Only its two open spans count.

The counted hours add up to 1.5 + 4.0 + 10.0 + 2.5 + 2.0 = 20.0. Five tickets were resolved, so MTTR is 4.0 business hours for P2 that week.

Without the rules, the same week gives 30.1 ÷ 6 = 5.0 hours. The duplicate dragged the average down; the hold time and the reopen gap pushed it up.

Ticket C alone is half of the 20.0 hours. MTTR is a mean, so one slow ticket moves it a lot. Read it beside the ticket count and the median from the metrics guide.

MTTR vs MTTA, MTTD, MTTF, And MTBF

MTTD measures detection delay; this guide's MTTR measures counted time after the ticket is logged.

NIST defines mean time to detect as the average time "a problem exists before it is found." ITIL treats MTBF as a reliability metric. It puts the time from one failure to the next at MTBF plus mean time to restore service.

For a small team, MTTR and MTTD point at different fixes. Long detection means better monitoring or users who report sooner. Fast acknowledgment with high MTTR points you toward diagnosis, parts, or handoffs.

Is There A Good MTTR Benchmark?

We found no recent neutral helpdesk benchmark with a stated sample. The figures that rank for this query are older, unsampled, or about production systems.

Even a good benchmark would compare clocks that don't match: one desk counts vendor waits, another pauses them, and some average P1 with P4. Compare your number with your own trend, per priority, under one written policy.

How To Reduce MTTR

Reducing MTTR on a small team is mostly about removing counted waits, not typing faster. Six changes, in the order we'd make them:

1. Get the details at intake

   A ticket that opens with "it's broken" costs counted hours while a technician reproduces the problem. Ask for the device and the error on the form or in the auto-reply. The user's reply time is excluded either way.

2. Route by category, with a backup owner

   Every transfer adds counted hours while the next person reads in. Send each category to the person who fixes it, and name a backup for when they're out. A handoff note lists the checks tried, their results, and the next action. Escalate when a ticket reaches half its completion goal without progress.

3. Set priorities everyone reads the same way

   Check impact and urgency at intake. Correct misclassified tickets before they enter the working queue, so urgent work reaches a technician sooner.

4. Watch the waiting clocks, not just the open ones

   Sort open tickets by how long the user has waited for your reply. Those hours count, so a ticket untouched for a day is MTTR you can still save.

5. Write down the fix you'll need again

   A knowledge base article for a fix you've done three times saves the counted search on the fourth.

6. Remove the longest counted wait

   Ticket C's six-hour parts wait counts. With a spare drive on the shelf, the sample drops from 4.0 to 2.8 hours (14.0 ÷ 5). Each month, pick the longest counted wait and assign one change to one person.

What doesn't work: closing before the user confirms, or splitting one problem into several fast tickets. Both flatter the number. Pair MTTR with reopen rate.

Resolution Clocks In SherpaDesk

About the author

Patrick Clements Co-founder & CEO, SherpaDesk

Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.

All Articles