Mean Time to Repair (MTTR): How to Measure and Cut It

Mean time to repair is the average elapsed time between an issue being reported and that issue being resolved, across a set of issues over a given period. If you fixed twenty items last month and they took, on average, three days each from report to close, your MTTR for the month is three days. It is a measure of speed and effectiveness combined — not how fast a single heroic fix went, but how your whole process performs across everything that came in.

It helps to be precise about which clock you are running, because "repair" can mean different things to different people. The broadest and most honest version starts when the issue is first reported and stops when it is verified fixed. Narrower versions exist — some teams only count the time a technician is actively working, which produces a flattering number that ignores the days an item sat in a queue. For maintenance and facilities work, the report-to-resolution version is the one that matters, because that is the time the person who reported the problem actually experiences.

MTTR is an average, which is both its strength and its trap. One catastrophic job that dragged on for six weeks can pull a month of otherwise quick fixes badly off course, and a single number hides that. Treat the mean as a headline, but always look at the spread behind it — the median, the worst cases, and how many items blew past their target. The average tells you the climate; the outliers tell you where the storms are.

The formula is straightforward: total repair time divided by the number of repairs. Add up the elapsed time for every issue resolved in the period, then divide by the count of those issues. If five repairs took 2, 4, 1, 8, and 5 days, the total is 20 days across 5 repairs, giving an MTTR of 4 days. The arithmetic is trivial; the work is in getting clean timestamps to feed it.

That means every issue needs two reliable times recorded: when it was reported and when it was confirmed resolved. "Reported" should be the moment the problem entered your system, not when someone got around to logging it — those can be days apart, and the gap is real delay you want to see. "Resolved" should mean verified done, not marked done, because an item reopened a week later was never actually closed. If your records only capture one of these times, or capture them loosely, your MTTR will be optimistic in ways you can't detect.

Calculate it in segments, not just as one company-wide figure. Break MTTR down by category — plumbing, electrical, structural, grounds — and by priority, location, and the team or contractor who handled it. A single blended number might look acceptable while hiding that one category or one site is running at triple the rest. Segmented MTTR is where the metric stops being a vanity figure and starts pointing at specific things you can fix. A monthly export of your issue log into a spreadsheet, with reported and resolved columns, is enough to start; the discipline of consistent timestamps matters more than any tool.

Most of the time in a slow repair is not spent repairing. It is spent waiting. The single largest source of inflated MTTR is usually the gap between an issue being reported and anyone acknowledging it — the report that lands in a shared inbox or a group chat and sits unread over a weekend. Nothing is being fixed during that time, but the clock is running, and to the person who reported it the delay is indistinguishable from neglect. Acknowledgement speed often matters more to perceived service than repair speed itself.

The second big sink is handoffs. Every time an issue moves between people — from the person who reported it, to a manager who triages it, to a technician, to a contractor who needs a part — there is a chance it stalls in the gap. Parts and procurement are a classic culprit: a job that needs a specific component can wait days for ordering and delivery, and that waiting time belongs to your MTTR whether or not you caused it. Unclear ownership compounds this; when an item has no single named owner, everyone assumes someone else has it, and it ages quietly in the backlog.

The third source is poor information at the start. A vague report — "tap broken in the building" with no photo, no exact location, no detail — forces a return visit just to diagnose what is wrong, and that round trip can double the repair time. Issues that are reported clearly, with a photo and a precise location, can often be assessed, parted, and scheduled in one pass. The quality of the first report has an outsized effect on the whole timeline, which is why fixing reporting at the source is one of the highest-leverage ways to cut MTTR.

MTTR rarely lives alone, and it is easy to confuse with its neighbours. Mean time between failures (MTBF) measures reliability — how long something runs before it breaks — while MTTR measures recovery, how fast you put it right once it does. The two together describe an asset's availability: long MTBF and short MTTR means something is dependable and, when it does fail, quickly back in service. You can have a great MTTR on equipment that fails constantly, so always read it alongside how often things break.

It also pairs naturally with response time and SLA compliance. Response time is the first leg of MTTR — report to acknowledgement — and is often governed by a service level agreement that sets a target. MTTR is the whole journey, report to resolution. Watching both tells you whether your delays are at the front of the process (slow to respond) or the back (slow to actually fix), and those two problems have completely different cures.

Finally, do not chase MTTR at the expense of first-time fix rate. If you push for speed by closing items fast and superficially, you will lower MTTR on paper while creating repeat visits that inflate it next month and frustrate everyone. A repair that is fast but doesn't hold is not a fast repair; it is a deferred one. The healthiest operations watch MTTR, first-time fix rate, and reopen rate together, so that speed and durability stay in balance rather than trading off against each other.

Start by attacking the waiting, not the working. Set a target for acknowledgement — every reported issue gets a human response within a defined window — and route reports automatically to the right person or category so nothing depends on someone happening to notice an inbox. Most of the easy minutes to recover are at the front of the process, before any tool or part is involved, and they cost almost nothing to claim once routing and acknowledgement are reliable.

Improve the quality of the report at the source. Insist on a photo and an exact location for every issue, so the person assigned can diagnose and prepare before they travel rather than discovering the problem on arrival. Give a single named owner to each item, with a clear status, so it can never quietly become nobody's responsibility. Build follow-up reminders into the workflow so that anything approaching its target gets a nudge before it breaches, rather than being discovered late in a monthly review.

Then measure honestly and review the outliers. Track MTTR by category and priority, and each month look specifically at the items that took longest — not to assign blame, but to find the pattern. Was it always a part on order? Always one contractor? Always the same building? The mean improves fastest when you fix the few worst cases, because they are the ones dragging the average up. A short standing review of your slowest repairs, backed by a clean log of reported and resolved times, will do more for MTTR than any amount of pressure to simply move faster.

SnagGrid is built to give you clean timestamps and to attack the delays that inflate MTTR in the first place. Every issue starts the same way: you snap a photo and drop a map pin, and the address auto-fills, so the report is precise and located from the first second. You add rough notes and AI drafts a clear, factual report you approve before it sends — it never invents facts, so the record is accurate and you skip the return visits that vague reports cause. The moment a report is created and the moment it is resolved are both logged to an audit trail, which gives you exactly the report-to-resolution timestamps an honest MTTR calculation needs.

Because SnagGrid emails the right recipient automatically and routes by category, the long acknowledgement gap that quietly bloats MTTR mostly disappears — reports don't sit unread in a shared inbox. One-tap follow-up reminders keep items from stalling between handoffs, and a team dashboard with roles shows every open issue and its owner at a glance, so nothing becomes nobody's job. When you want to analyse MTTR properly, CSV export drops your full log into a spreadsheet for segmenting by category, priority, or site, and a scoped REST API with webhooks feeds the same data into your own reporting. Pricing is $29 per month per organization for one seat, plus $15 per month for each extra seat — so measuring and cutting mean time to repair stops being a manual reconstruction and becomes something your records produce automatically.