Time to restore in an agent-heavy codebase
The most robust of the four keys hides a phase that agentic development makes much harder. Restoring service is unchanged. Working out what to restore is not.
Every incident I have ever sat in has the same shape. There is a stretch at the start where nobody knows what is happening, and then there is a moment where somebody says “it’s the thing we shipped at four,” and then there is a stretch of doing the obvious thing. The second stretch is engineering. The first stretch is detective work, and it is almost always the longer of the two.
Time to restore service measures both stretches as one number. That was fine for a long time, because both stretches were roughly proportional to how bad the incident was, so the total tracked severity reasonably well and improvements to either one showed up.
Under the Agentic Development Life Cycle, the two stretches decouple. The second stretch, the fixing, gets faster: better rollback tooling, smaller changes, feature flags, and an agent that can produce a fix in minutes once you know what the fix is. The first stretch, the working-out, gets harder for reasons that are structural rather than incidental. And the total is the sum, so the metric may not move at all while the experience of being on call changes considerably.
Why diagnosis got harder
Four things changed, and none of them is about agents writing bad code.
The change set got bigger. When an incident starts, the first question is what changed. Under the old model, a day’s change set for a team was a handful of pull requests you could read in ten minutes and mostly recognise, because you had reviewed some of them and heard about the rest at standup. Now the same window can contain five times as many changes, most of which nobody has held in their head. The search space for “what did we do to ourselves” multiplied.
The changes are no longer memorable. This is the one people underestimate. Human-authored changes carried an enormous amount of implicit context in the heads of the people who made them. During an incident, that context surfaced in the form of somebody going “wait, I touched that on Tuesday and I was nervous about it.” That instinct was doing a huge amount of triage work, invisibly and for free. An agent-authored change nobody felt nervous about produces no such instinct. The information exists in the diff, but not in anybody’s memory, and during an incident memory is much faster to query than a diff.
Correctness signals are weaker. A human-written change that was rushed usually looks rushed. Sparse tests, a terse description, a commit message that says “fix”. Reviewers used those signals unconsciously to allocate attention, and during incidents responders used them to rank suspects. Agent-authored changes look uniformly finished: full tests, tidy diff, well-written description. That uniformity removes the ranking signal. Every suspect looks equally plausible.
Blast radius is less predictable. Agents refactor readily and touch files a human would have left alone, partly because renaming forty call sites costs nothing. The correlation between “this change was about area X” and “this change can only break area X” is weaker than it used to be.
Add those together and the diagnostic phase of an incident, which was already the longer half, gets longer while the repair phase gets shorter. Whether the total moves depends on the ratio, which varies by team. It is entirely possible for a team to see a completely flat time to restore while their on-call engineers report that incidents have become substantially more unpleasant. Both are true.
What the metric is actually anchored to
Time to restore is the least gameable of the four keys, which is why I called it the most robust. It is anchored to a fact about users: service was bad, then it was good. You cannot inflate it by producing more code and you cannot deflate it by producing less.
The problem is not gaming. The problem is availability. Very few organisations have a clean, consistent stream of incident-start and incident-resolved events that is comparable across teams, because incident-start is a human judgement about when something became bad enough to count, and different teams draw that line in different places. The metric is honest and its inputs are mushy.
This is the reason our own implementation derives time to restore from high-severity findings, measured from raised to resolved, rather than claiming to measure user-visible outage. A high-severity finding raised against the repository has an unambiguous timestamp and an unambiguous resolution. It is a narrower thing than a production incident, and the number will not match what your incident management tool says. It is also computable from the data we can actually see, and stating that basis on the surface is what allows a reader to know which of the two they are looking at. When there are no such findings in the window, the metric returns nothing rather than zero, because a team with no findings does not have an instant restore time, it has no measurement.
I labour this point across the series because the alternative is the thing that makes measurement worthless: printing a strong label over a weak computation and letting the reader assume the strong version.
Time to restore is the least gameable of the four keys because it is anchored to a fact about users: service was bad, then it was good.
The problem is not gaming, it is availability. Very few organisations have a clean stream of incident-start and incident-resolved events, so the metric gets derived from a weaker proxy and labelled as though it were the real thing.
Splitting the interval
If you take one operational suggestion from this piece, take this: measure detection, diagnosis and repair as three intervals rather than one.
Detection. Something broke to something noticed. This is the interval your monitoring owns. Agentic development does not change it much, though a higher change rate arguably makes good alerting more valuable, because the “somebody will notice” fallback degrades when nobody has a mental model of what shipped today.
Diagnosis. Noticed to cause identified. This is the interval I have argued is degrading, and it is the one almost nobody measures separately, because under the old model it was not separately interesting. It is now the most informative number in your incident data.
Repair. Cause identified to service restored. Agents make this faster and rollback tooling makes it much faster. If you have invested in this, you will see it here, and you will not see it in the total if diagnosis is eating the gains.
Splitting the interval requires exactly one behaviour change: somebody notes the timestamp when the cause is identified. That is it. No new tooling, no vendor, no integration. In practice a bot that watches for a message in the incident channel gets you most of the way. The value of that single extra timestamp under the ADLC is, I think, larger than the value of most metrics programmes I have seen.
Making diagnosis cheaper
The measurement points at the problem. Three things actually reduce it, and all three are about the change record rather than about observability.
Make every change traceable to an intent. During diagnosis, the question is never really “what code changed”, it is “what were we trying to do”. A change linked to a work item with real acceptance criteria answers that in one hop. An unlinked change means reading the diff and inferring. Multiply by a large change set at three in the morning. The share of merges with no linked work item, which I recommended tracking in an earlier piece for entirely different reasons, turns out to be an on-call quality metric too.
Keep changes small and independently revertible. This is old advice and agents make it cheap for the first time. The value under the ADLC is specifically diagnostic: a small change either is or is not the culprit, and you can test that by reverting it. A large change forces you to understand it before you can act on it, and understanding is the slow part.
Preserve the reasoning, not just the result. When an agent produced a change, the deliberation that a human would have carried in their head, why this approach, what was rejected, what the risky part is, either got written down or evaporated. Teams that capture even a sentence of that in the pull request description are meaningfully faster during diagnosis. Teams that do not are reading generated prose that describes what the change does, which they can already see, rather than why, which they cannot.
Notice that none of these is an observability purchase. Observability tells you what is happening now. Diagnosis under the ADLC is bottlenecked on understanding what was intended recently, and that lives in the change record.
Where this breaks down
I want to be careful, because this piece rests on a claim I cannot prove.
The core claim is that diagnosis is getting harder in agent-heavy codebases. My evidence is mechanism and anecdote: the mechanisms are real and the anecdotes are consistent, but I have no measurement, and neither does anyone else, because almost nobody splits the interval. It is entirely possible that better tooling, particularly agents used for diagnosis rather than construction, will offset the loss of human memory. An agent that can read the entire day’s change set in seconds and correlate it against a stack trace is doing exactly the work I claimed got harder, and it does not get tired at three in the morning. If that becomes routine, the diagnosis interval could improve rather than degrade, and this piece will read as a period document.
Second, time to restore is a badly behaved statistic for most teams because incidents are rare. A team with three incidents a quarter has no meaningful average, and computing one produces a number driven entirely by whether one incident happened to be nasty. Aggregating across teams to get sample size means aggregating across different definitions of what counts as an incident, which is not really aggregation. For most organisations, the honest thing is to read the incidents individually and stop pretending the average means something.
Third, the finding-based proxy I described has a real weakness: it measures a class of problem that is detected by analysis rather than by users. Those populations overlap but they are not the same, and a team could have a healthy finding-resolution time and a terrible outage-restoration time. The proxy is useful precisely because it is available everywhere, and it should never be presented as a substitute for actual incident data where actual incident data exists.
Fourth, there is a perverse incentive lurking in splitting the interval. Once “cause identified” is a measured timestamp, there is pressure to declare a cause early, and declaring a cause early is how you end up fixing the wrong thing twice. If you split the interval, be explicit that a re-opened diagnosis is normal and not a failure, or you will get faster diagnosis timestamps and slower actual restoration.
The takeaway
Time to restore is the most robust of the four keys and the one least distorted by agentic development, which is exactly why the change hiding inside it is easy to miss. Repair is getting faster. Diagnosis is getting harder, because the change set is larger, less memorable, uniformly polished, and less predictable in blast radius. The total can sit perfectly still while both halves move.
Split the interval. One extra timestamp, at cause identified, tells you which half you are in. Then invest in the change record rather than in more dashboards, because diagnosis is bottlenecked on recovering intent, and intent lives in the link between a change and the thing it was meant to do.
The next piece steps back from the individual keys and asks the awkward question the whole series has been circling: how a team can post elite scores on all four while the board rots underneath them.