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.
Key takeaways
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.
Definition
Mean time to resolution (MTTR) is the sum of the counted resolution hours of the tickets resolved in a period, divided by the number of those tickets. Report it per priority, in business hours or clock hours, never both mixed.
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.
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.
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.
| MTTR | Clock starts | Clock stops | Typical setting |
|---|---|---|---|
| Mean time to repair | The failure | The repair is complete, before recovery or restore | Equipment and component repair |
| Mean time to recovery (or restore) | The failure | The service is back to normal for users | Outages of a service or system |
| Mean time to respond | The ticket or alert arrives | Someone answers or starts diagnosis | First answer on a call, ticket, or alert |
| Mean time to resolve (resolution) | The ticket is logged | The user confirms the fix or workaround | Helpdesk tickets |
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.
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.
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:
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.
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.
Subtract the documented hours the ticket waited on the user, as the table below sets out.
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.
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.
Our SLA management guide covers when the SLA clock may pause. This guide's MTTR policy keeps vendor waits in.
| Situation | In MTTR? | Why |
|---|---|---|
| Documented waits on the user (a reply, a screenshot, a time to call, the fix confirmation) | Out | The next move is the user's. Report these hours on their own |
| Waiting on a vendor, parts, or the ISP | In | The user is still stuck, and stocking or escalating is your call |
| Nights and weekends outside the priority's hours | Out | The calendar already excludes them |
| A reopened ticket, same problem | In, both open spans | The first fix didn't hold; the hours while closed stay out |
| A duplicate merged into another ticket | Out | Counting it adds a fake fast close |
| Tickets still open at period end | Out | No end time yet. Report the open count and the oldest age |
| Spam and tickets closed as junk | Out | No user problem to resolve |
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.
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 | What happened | Logged to resolved | Counted |
|---|---|---|---|
| A · Outlook won't open | Profile rebuilt on the first call | 1.5 h | 1.5 h |
| B · VPN fails for a remote user | On hold 3 h waiting for the user to be free for a call | 7.0 h | 4.0 h |
| C · Laptop drive failed | 6 h waiting on the vendor's replacement drive | 10.0 h | 10.0 h |
| D · Shared drive access | Logged Mon 9:00, confirmed resolved 10:00; reopened Tue 8:00, confirmed resolved 9:30 | 9.5 h | 2.5 h |
| E · Printer offline | Duplicate of F, merged | 0.1 h | Not counted |
| F · Printer offline | Driver reinstalled | 2.0 h | 2.0 h |
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.
MTTD measures detection delay; this guide's MTTR measures counted time after the ticket is logged.
| Metric | Measures | Helpdesk example |
|---|---|---|
| MTTR, mean time to resolve | Logged to verified fix, counted hours | 4.0 business hours for P2 |
| MTTA, mean time to acknowledge | Logged to a person taking ownership | The ticket is assigned and the user hears back |
| MTTD, mean time to detect | A problem exists to someone finding it | A failing backup noticed on day three |
| MTTF, mean time to failure | Running time before an item that isn't repaired fails | Laptop batteries you replace, not repair |
| MTBF, mean time between failures | Running time between failures of something you repair | Operating hours from restoration until the firewall's next failure |
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.
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
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.
Reducing MTTR on a small team is mostly about removing counted waits, not typing faster. Six changes, in the order we'd make them:
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.
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.
Check impact and urgency at intake. Correct misclassified tickets before they enter the working queue, so urgent work reaches a technician sooner.
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.
A knowledge base article for a fix you've done three times saves the counted search on the fourth.
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.
Reducing MTTR on a small team is mostly about removing counted waits, not typing faster.
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.
How this works in SherpaDesk
You can check response and completion against goal in the SLA report, which isn't this guide's MTTR. Under Reports > SLA & Priority, it covers closed tickets with an On-Time Report and a Goal vs. Actual Report. After a reopen, completion time restarts from the latest reopening, so Ticket D would show its final 1.5-hour span, not 2.5.
Export ticket data to CSV, XLS, or XML. Add your recorded reopen spans and user waits before calculating MTTR in a spreadsheet. The same queue serves your own staff or your clients.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, so a team of three pays $90 a month ($80 per month, billed annually). The trial is 14 days free with no card.
Who this isn't for
SRE and DevOps teams tracking MTTR for production systems with incident-response platforms.
Take one priority's tickets resolved in a period. Count each from logged to verified resolution on that priority's calendar, minus documented user waits and closed time. Divide the total by the number of tickets.
It can be, once the clock rules are written down and the number is reported per priority. Pair it with first response time and reopen rate, so a fast close that didn't hold shows up instead of improving the score.
Mean time to failure (MTTF) is the average running time before an item you don't repair fails, such as a laptop battery you replace. For things you repair, like a firewall, the matching measure is mean time between failures (MTBF), which ITIL treats as a reliability metric. To calculate MTBF, add up the running time between failures and divide by the number of failures.
They're priority levels, from P1, the most urgent, to P4, the least. Report MTTR separately for each, because a P1 outage and a P4 request run on different clocks. Our guide to ticket priority levels defines all four and the targets that go with them.
Lists differ by source. Our guide uses seven, running from logging one ticket with a priority, through restoring service and confirming with users, to handing off to the review. The steps and a worked outage are in our incident management process guide. This guide counts logging to user-confirmed resolution, minus documented user waits and closed gaps.
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.