MTTR — Mean Time To Repair

MTTR is only useful if everyone agrees on what "repair time" actually means — and that's where most plants trip up, because the number quietly absorbs delays that have nothing to do with wrenches turning.

What the clock actually measures

A breakdown work order doesn't have a separate "repair started" timestamp — it has a report time and a completion time. That means the MTTR window includes everything sitting inside it:

• Approval delay before a technician is assigned
• Spare-parts wait, if the part isn't on hand
• Vendor travel time for outsourced repairs
• The actual hands-on repair

AssetAI's clock starts the moment the machine-stopped flag is set on a breakdown (BM) or corrective (CM) work order, and stops only when that work order is marked complete through its one-tap closure action. Preventive and other work order types don't carry this clock at all, so they're excluded from the calculation entirely. One exception worth knowing: emergency-severity breakdowns skip the approval step and raise the work order immediately at submit, which shortens the report-to-work-order gap for those cases specifically — but doesn't change how the rest of the clock behaves.

If your MTTR trend looks worse this month, the honest first question isn't "are repairs slower" — it's "did approval or parts availability get slower." The number won't tell you which on its own.

Where the figure lives, and where it doesn't

MTTR shows up in two places inside AssetAI, and they're deliberately not the same calculation:

• A fixed 30-day tile on the company dashboard, alongside downtime cost, downtime hours, and PM compliance
• A recomputed tile inside OEE & Analytics, over a rolling window you choose — 30, 90, 180 or 365 days, defaulting to 90

Because these use different windows, they can legitimately disagree — a spike that fell out of the 30-day tile may still be dragging down the 90-day view. Neither figure is broken down by asset, failure mode, or criticality by default; that level of detail lives in the Analytics/OEE and RRR views, not in the MTTR tile itself. And there's no threshold alert tied to MTTR — it's a trend you read, not a number that pages you.

Why the underlying data holds together

MTTR isn't computed in isolation. It draws from the same downtime-hours and failure-count pools that feed their own dashboard tiles, so the figure is really that shared downtime total divided by that shared failure count over the window. Every one of those repair records also carries a mandatory failure cause and remedy — closure is blocked without both — which means the same work orders that build your MTTR also build your failure Pareto. The two numbers trace back to each other, which is useful when you're trying to work out whether a rising MTTR is a parts problem, an approval problem, or a genuinely harder failure mode.

For teams building out a broader KPI set — MTTR alongside OEE and TPM-style metrics — it's worth reading up on Total Productive Maintenance as a frame for where MTTR fits. See how the rest of the KPI set comes together across features, or book a demo on your own plant's data instead of a slide deck.

Reading MTTR correctly means knowing what it can and can't tell you before you act on it — otherwise a fleet-wide average ends up driving decisions it was never built to support.

Using MTTR without over-reading it

MTTR on AssetAI is a single aggregate number for the window you've selected — it doesn't split out by asset, failure mode, or criticality by default. That's a deliberate trade-off: the tile answers "is our overall repair speed trending up or down," not "which machine is dragging the average up." For that second question, you need to look at OEE and RRR views, where downtime and stoppages are broken down per asset. Treat the MTTR tile as a trigger for investigation, not as a diagnostic in itself.

A related point worth flagging to your team: the dashboard shows a fixed 30-day MTTR tile, while the Downtime Cost, OEE & Analytics page recomputes MTTR over whatever rolling window you pick — 30, 90, 180, or 365 days, defaulting to 90. These two numbers are calculated independently and can legitimately disagree. If someone quotes "this month's MTTR" from the dashboard and someone else quotes a 90-day figure from analytics, they're not talking about the same thing. Pick one view as your standing reference for reviews and stick to it.

Common mistakes plants make with MTTR

Most of the ways MTTR gets misread aren't calculation errors — they're interpretation errors:

• Comparing MTTR across sites without accounting for spares stocking or vendor distance. A plant with parts on hand and in-house technicians will show a lower MTTR than one waiting on outsourced vendors, regardless of actual repair skill.
• Reacting to a single bad week. Because MTTR is downtime hours ÷ failure count over a window, one long outlier repair (a vendor delay, a rare part) can swing the average disproportionately when the failure count is low.
• Assuming MTTR breaches trigger alerts. They don't — there's no SLA or notification tied to this KPI in AssetAI today, so watching the trend has to be a deliberate habit, not something the system pushes to you.
• Trying to fix the clock retroactively. If the machine-stopped flag was set incorrectly at report time, there's no way to annotate or correct the downtime clock after the fact — which is one more reason to get the flag right at the point of reporting, not after.

For plants running under TPM or formal reliability programs, MTTR is usually reviewed alongside MTBF and OEE rather than in isolation — worth keeping in mind if you're benchmarking against ISO or industry-wide reliability standards. If you're setting up these KPIs for the first time, the what is a CMMS primer covers where MTTR sits relative to work order management generally, and /contact is the fastest way to see how AssetAI's dashboard renders this for your own plant's data.