MTTR is the operational metric most closely tied to what an incident costs your users. Not alert volume, error rate, or ticket count. Resolution time covers the period when service is degraded, transactions fail, and user trust declines. The other reliability measures ultimately lead back to it.
Most teams attack MTTR in familiar ways: add on-call engineers, tune alert thresholds, and improve runbooks. Those changes help, but only up to a point. The response loop still relies on someone being awake, opening the alert, building context, and choosing the next action.
Where the Time Actually Goes
Divide a typical P2 incident into phases and the same pattern appears. With properly tuned monitoring, detection often takes only a minute or two. The alert may then wait for human acknowledgment. Most time disappears between acknowledgment and diagnosis: an engineer joins a call, opens dashboards, compares service metrics, checks the runbook, tries one remediation that fails, then tries another.
While building Cordant, we found a typical P2 latency spike in a multi-service system breaks down roughly this way: detection takes 1 to 3 minutes, followed by 3 to 12 minutes for human acknowledgment, and longer at 3am. Diagnosis takes 15 to 40 minutes when the engineer lacks existing service context. The first remediation attempt comes around minute 20 to 45. If that approach works, resolution usually arrives 10 to 20 minutes later.
That adds up to 35 to 75 minutes, versus 8 to 10 minutes for a prepared responder who already knows the system.
The Compressible and Non-Compressible Phases
Those phases do not all shrink at the same rate. Monitoring can make detection faster, but gains diminish quickly. Human acknowledgment has a lower bound imposed by sleep and attention. Better code cannot solve those human constraints.
Diagnosis and choosing the first action are separate steps. Both can shrink, and for many incident types they can approach zero. The diagnostic process must be repeatable from the available signals, and the remediation must have a known safety profile. When both are true, there is no fundamental reason for a person to perform the work.
Autonomous remediation is not meant for every incident. It handles categories that meet those conditions from start to finish, involving a human only when the diagnosis is unclear or the action calls for judgment the system cannot make with sufficient confidence.
A Faster Incident Timeline in Practice
Take a checkout service with rising latency caused by a pod resource constraint. Under a conventional on-call model, the sequence is a 2am page, a sleepy engineer, 20 minutes of dashboard review, a scale-out command, and a follow-up ticket. User impact totals 35 to 50 minutes, depending on how quickly the engineer wakes.
Cordant detects the anomaly within the first monitoring interval and traces the signal: latency rises, CPU saturation on checkout pods correlates with increased order volume, memory remains within bounds, and no upstream dependency fails. Diagnosis: resource constraint. Scale-out is appropriate. Action: scale checkout pods from 3 to 8. From first anomaly to applied fix, the sequence takes under 4 minutes. The on-call engineer receives a notification that the incident was detected and resolved, with what happened and the timeline.
The engineer was not woken. The checkout service recovered before most users saw a problem.
When Autonomous Action Should Not Fire
The limits need to be explicit. Some incidents do not match this pattern. If the failure is genuinely novel, the signals do not establish causality, or the available remediations could materially worsen the situation, autonomous action should wait for human approval.
That is not a flaw in the model. It is the intended boundary. An autonomous SRE agent that acts on everything will quickly lose engineer trust. Calibration matters more than broad coverage. Handling 60% of incidents autonomously while escalating the remaining 40% with useful diagnostic context is far more valuable than attempting 100% and being wrong 15% of the time.
During our early-access beta, we spent more time adjusting confidence thresholds and escalation rules than on any other individual feature. We repeatedly asked: for this incident pattern and this confidence level, does autonomous action reduce risk or add to it? The answer depends on the incident type, the environment, and the quality of the runbook supporting the action.
Measuring the Improvement Correctly
Measure carefully when adding autonomous remediation to the incident stack. Raw MTTR will fall, but not by the same amount everywhere. Categories handled autonomously may see an 80 to 90% MTTR reduction. Incidents that still reach humans may improve less because they truly need human judgment, which takes time.
A stronger baseline is user impact minutes: the number of minutes per week users spend with degraded service across all incidents. That figure should fall substantially as autonomous resolution catches frequent, shorter incidents before they compound.
Also track how often on-call engineers are interrupted. Total incident volume may remain flat, yet cutting the incidents that require someone to wake at 3am directly affects team health and retention. The effect is difficult to measure precisely, but it is real.
Architecture Behind Autonomous Remediation
Autonomous remediation depends on observability that supports accurate diagnosis. Coarse metrics, traces that stop at service boundaries, and noisy alerts unrelated to real problems will cause the agent to miss incidents or diagnose them incorrectly.
That requirement creates a useful forcing function. Preparing for autonomous remediation tightens observability in ways that also help human responders. Higher-quality signals speed diagnosis for incidents that still escalate. The investment compounds.
MTTR reduction is ongoing work, not a one-time project. It comes from continually shortening each phase of the response loop, and autonomous remediation removes the hard lower bound that human response time has imposed on that work.