MTTR is still useful. It tells teams whether production gets back to a healthy state quickly enough.
But it is not the only clock that matters anymore.
When the remediation workflow can connect observability, deploy history, code ownership, and AI-generated patches, a new metric becomes practical: time-to-reviewed-PR.
What the metric means
Time-to-reviewed-PR measures the path from a production signal to a pull request that a code owner can seriously evaluate.
Not a random generated diff. Not a vague incident summary. A reviewable PR.
That means the pull request includes:
- the production signal that triggered the investigation
- the suspected service, file, function, or code path
- the recent deploy or change set that may be related
- a focused patch
- the tests that ran or should run
- the assumptions and confidence level
- the right reviewer or owner
The metric ends when the PR is ready for a meaningful engineering decision.
Why this is different from MTTR
MTTR is outcome-oriented. Time-to-reviewed-PR is workflow-oriented.
MTTR asks, "When did we recover?"
Time-to-reviewed-PR asks, "How quickly did we get to a high-quality decision point?"
That distinction matters because many incidents are delayed before the code change even exists. Engineers are still collecting evidence, finding ownership, comparing deploys, or deciding whether the issue belongs to another system.
If the team can shorten that phase, recovery often improves naturally. Even when the final answer is rollback or escalation, the decision happens with better evidence and less confusion.
The quality bar
The metric only works if "reviewed PR" means something strict.
A bad version of this metric would reward tools that open noisy pull requests quickly. That creates review fatigue and makes engineers distrust automation.
A good version rewards prepared, scoped, evidence-backed work.
The PR should be small enough to review, clear enough to reject, and connected enough to production evidence that the reviewer does not have to reconstruct the incident from scratch.
Useful companion metrics
Time-to-reviewed-PR should not stand alone. Pair it with quality signals:
- PR acceptance rate
- reviewer edit rate
- false diagnosis rate
- rollback rate after AI-assisted fixes
- duplicate incident rate after merge
- time from PR open to reviewer decision
Together, these metrics show whether automation is saving time or simply moving work into review.
Where this helps leaders
Engineering leaders need to know whether incident tooling reduces operational drag. A chart that says recovery is faster is helpful, but it does not explain where the time went.
Time-to-reviewed-PR makes the handoff visible. It shows whether the team can move from alert to evidence, from evidence to code, and from code to ownership without manual stitching.
It also exposes weak links. If PRs open quickly but sit unreviewed, the problem is ownership or staffing. If evidence takes too long, the problem is integration. If many PRs are rejected, the problem is diagnosis quality.
The point is not more metrics
The goal is not to invent another dashboard for engineers to ignore.
The goal is to make remediation quality observable.
Production bugs are not solved when an alert fires, and they are not solved when a model writes code. They move toward resolution when the right human can make a confident decision with the right evidence in front of them.
That is what time-to-reviewed-PR measures.
