Most engineering orgs track mean time to resolution like it's the scoreboard. It isn't. MTTR tells you how long an incident lasted. It says nothing about why it happened, whether it will happen again, or whether the fix actually addressed the cause.
That gap is where automated root cause analysis is supposed to help. In practice, most teams don't have it. They have Slack threads, a postmortem doc nobody rereads, and a rough sense of "the deploy on Tuesday broke something." RCA is the part that runs after something breaks; for the prevention side of this, see why AI-generated code needs a different kind of pre-screening.
What MTTR actually measures
Mean time to resolution is the average time between an incident starting and it being marked resolved. It's easy to calculate, easy to put on a dashboard, and easy to misread.
A team can improve MTTR by getting faster at rolling back. That's a real skill. It's also completely disconnected from whether the underlying problem gets fixed. Roll back fast enough, often enough, and MTTR looks great while the same class of bug keeps resurfacing under a different symptom.
MTTR is a lagging indicator of response speed. It was never built to measure root cause quality. Most postmortem processes quietly fail right here, treating a speed metric as a reliability proxy.
Why root cause analysis usually stalls
Manual RCA has a structural problem: it competes with everything else on an engineer's plate. The incident is over. The page has stopped. And the person best positioned to dig into why it happened is also the person under the most pressure to move on to the next thing.
So the analysis gets done at whatever depth fits the time available. Sometimes that's a real investigation. More often it's "we added a null check" — a fix for the symptom, not the condition that produced it.
This is where AI-generated code makes things worse, not better. Code volume per engineer keeps climbing as AI assistants speed up the writing part. Review and root cause analysis haven't sped up to match. More changes now ship through the same review capacity. That means more opportunities for a subtle failure mode to slip through, and less time to trace it back when it does. This is one of the failure modes the Tomosu team has been documenting publicly as part of building around it.
What automated root cause analysis needs to actually do
Automating RCA isn't about generating a plausible-sounding explanation faster than a human would. A lot of tools stop there, and it shows: confident, well-formatted, and wrong.
A useful automated RCA process needs three things.
Correlate the incident with the actual code change
Not just the deploy timestamp. Most outages trace back to a specific diff. If the tooling can't connect "this broke" to "this line, in this PR, changed this behavior," it isn't doing root cause analysis. It's doing timeline reconstruction.
Distinguish the trigger from the cause
The trigger is what happened right before the incident. The cause is the condition that made the trigger dangerous in the first place. A traffic spike is a trigger. Missing backpressure handling is the cause. Tools that stop at the trigger produce fixes that patch the symptom, and the cause stays in place waiting for the next trigger to find it.
Feed back into prevention, automatically
A root cause analysis that lives in a postmortem doc helps exactly one incident. The same failure pattern showing up as a merge-gate check on every future PR helps all of them. But that only works if the loop closes fast. If going from "we found this" to "this is now blocked at review time" takes weeks of manual policy-writing, it won't happen consistently, and the same class of incident resurfaces under a different name in six months.
MTTR is one metric in a family, and the family has the same blind spot
MTTR definition, quick version: mean time to resolution, the average time from an incident starting to it being marked resolved. It's one of the four DORA metrics, the closest thing the industry has to a shared standard for measuring delivery performance. It usually sits alongside a couple of relatives that get less attention but shape the same picture.
Mean time to acknowledge is how long it takes someone to notice and claim an incident after it fires. Mean time to respond is how long until someone starts actively working it. Teams that track MTTA and MTTR side by side are usually trying to separate "we were slow to notice" from "we were slow to fix," which is a reasonable split. It's still measuring speed on both ends, not correctness.
That's the pattern worth naming: every metric in the MTT* family answers "how fast," and none of them answer "did it actually get fixed." So when someone asks how to reduce MTTR, the honest answer is that it's the wrong question if the goal is fewer incidents. Faster rollbacks reduce MTTR. They don't reduce how often the same failure shows up.
The metric that actually matters
Track how often the same root cause resurfaces. Not MTTR — recurrence.
An incident that gets root-caused and closed for good is one outcome. An incident that gets rolled back, marked resolved, and shows up again in a different form next quarter is another. MTTR treats both the same. Recurrence rate doesn't.
That's the number worth putting on a dashboard, and it's a much harder one to fake by getting faster at rollbacks.
Tomosu builds merge-gate governance infrastructure that connects what broke in production back to the change that caused it, and turns that finding into a check on every future PR. If you're operating AI-assisted development at scale and the same class of incident keeps returning, we are opening a small design partner cohort. Book a call →