How do you measure MTTR honestly?

The many M's, and where they get conflated

MTTA is mean time to acknowledge, the gap between a signal firing and a human or system responding to it. MTTD is mean time to detect, the gap between a problem starting and it being noticed at all. MTTR is ambiguous by design in most marketing: it can mean mean time to resolve (the ticket is closed) or mean time to repair (the underlying fault is actually fixed), and those are different clocks that can differ by hours. A vendor quoting "MTTR" without saying which R, and without saying what event stops the clock, has not given you a comparable number.

How the clock gets quietly redefined

The start event can be the incident's actual onset, the first alert, or the first human page, and each choice changes the number without changing anything about how fast the team actually worked. The end event can be the ticket status change, the fix being deployed, the fix being verified, or the customer being notified, and each of those can be minutes or hours apart. Outlier handling matters just as much: a single long-running incident dropped from the sample, or reclassified as "planned maintenance," can move an average meaningfully in a small dataset.

A concrete, sourced example of the caution

Vendor launch material in this category routinely carries improvement percentages, diagnostic-accuracy figures and one dramatic before-and-after case, without the methodology, the sample size or an independent audit behind them. That does not make the numbers wrong. It means they are not yet verifiable by a third party, which is the exact gap this checklist is meant to catch, in any vendor's claims, including ours. The question to put to any published figure is the same: what population was it measured over, against what baseline, and who other than the vendor has checked it?

A checklist for an honest MTTR number

Five questions turn an unverifiable percentage into a comparable one.

• What is the exact start event and end event, named precisely enough that someone else could reproduce the measurement?
• What is the sample size and time window, and were any incidents excluded, and by what rule?
• Is the number self-reported by the vendor, measured by the customer, or audited by an independent third party?
• Is there a stated before-and-after baseline, measured over the same population of incidents, rather than a single anecdote?
• Does the vendor say what it has not yet measured, or does every number in the material read as a finished result?

How HELM by LockedIn Labs handles this, and what we have not yet proven

Every indicator on the Scorecards view, including MTTA and MTTR, names the snapshot field or formula it was computed from, and a service-objective registry carries the owner, target, and window for each one. The reference deployment's data is synthetic and labeled as such; forecast, impact, and service-level figures in the predictive episode are explicitly modeled, not customer measurements, and the product says so on screen rather than in a footnote.

The honest limit: HELM by LockedIn Labs has not yet run an independently measured before-and-after MTTR at a live customer either. A written measurement protocol for exactly that exists and is ready to run with a design partner, but it has not produced a publishable number yet. We say that plainly rather than let a demo imply otherwise.

Why this matters beyond a single vendor comparison

An organization that adopts a shorter internal MTTR target without agreeing on the clock definition first often ends up optimizing the definition instead of the outcome: teams learn which incidents to reclassify, which ones to mark as planned, and when to close a ticket versus verify a fix, and the number improves while the customer experience does not. That risk exists whether or not any AI is involved; agentic tooling just makes it easier to hit a target quickly, which raises the stakes of getting the definition right first.

The same discipline applies inside a single organization comparing its own before-and-after numbers, not only when comparing across vendors. If a team changes its incident-classification rules at the same time it adopts a new tool, the resulting MTTR delta measures the classification change and the tool together, and there is no way to separate the two after the fact without having fixed the definition beforehand.