200 incidents have now gone through Cordant in early-access beta with a small group of platform teams. In each case, Cordant attempted to detect the anomaly, identify the root cause, choose and apply a fix, and verify recovery without paging a human. This post reports what we observed.
This is internal beta data from a small group of early-access pilots, not broad production data. These figures describe observed results, not forecasts. We are publishing them because the pattern is useful at this stage.
A Look at the 200 Incidents
The 200 beta incidents were unevenly distributed. Most fell into common cloud-service categories: resource exhaustion, dependency timeouts, traffic-spike-related error increases, and pod instability after recent deployments.
The approximate split was: resource exhaustion, including memory, CPU, and pod count, made up about 38%. Dependency latency spikes represented around 29%. Error-rate increases with identifiable upstream causes accounted for another 21%. The final 12% combined certificate expiry, configuration drift, and queue backups.
All 200 qualified for autonomous action because diagnosis confidence was above the threshold when each incident began. Cordant withholds action when confidence is low, escalating instead with its diagnostic findings attached.
Resolution Rate and Its Drivers
Cordant resolved 152 of 200 attempts cleanly without human intervention, producing a 76% autonomous resolution rate in this sample. The other 48 escalated after the first autonomous action failed to resolve the incident or changed circumstances reduced confidence below the action threshold.
Results differed materially by category. Resource exhaustion led at about 89% clean autonomous resolution. Dependency latency reached about 71%. Error-rate incidents were lower, around 65%, since elevated errors often have a less deterministic connection to one specific remediable cause.
The 24% escalation share does not mean that no work was completed. Cordant had taken partial action in 41 of those 48 cases before deciding that human judgment was required. Each escalation included the attempted-action timeline, current system state, and diagnosis summary. The responder inherited an incident already partly worked, not a blank slate.
Where Autonomous Action Fell Short
A useful account must cover the cases that did not work, not just the successful ones.
Incidents with several simultaneous failure modes were the most difficult. When two problems occur together, diagnostic confidence falls because the signals no longer map neatly to one runbook. For example, a deployment that produces both a memory leak and a downstream timeout leaves an unresolved question: did the memory problem cause the timeout, or is there a separate upstream fault? Cordant escalated these cases rather than guessing. The handoff was weaker, however, because shared causality remained unresolved.
Performance also declined when service observability was incomplete. Missing metrics, or metrics that do not cover the failure mode in question, leave diagnosis with partial evidence. The basic rule applies here too: poor inputs produce poor outputs.
A third gap involved failure modes absent from the existing runbooks. These cases are difficult for autonomous systems because they need either a new runbook or human expertise. Cordant escalated them correctly, but the summaries were less useful because no prior pattern was available for comparison.
How Incident Timelines Changed
For autonomous resolutions, time-to-resolution matters more than the resolution percentage. Across 152 clean autonomous resolutions, the median interval from first anomaly detection to confirmed recovery was 4 minutes 20 seconds. The 90th percentile was 11 minutes.
Before Cordant was enabled, the same incident types in the same beta pilots had a median manual MTTR of around 34 minutes. The reduction was substantial, though it varied by time of day. Incidents occurring between midnight and 6am local time improved the most in absolute terms because human acknowledgment took longest during that period.
What We Are Still Improving
The 76% autonomous resolution rate is not a limit. Two factors account for much of the gap: confidence thresholds that are unnecessarily cautious for well-understood incident types, and missing runbook coverage in the long tail.
Threshold selection is primarily a calibration issue. During early beta, we set thresholds conservatively because unnecessary escalation was preferable to an incorrect fix. As more data identifies incident-type and action combinations with high success rates, thresholds can be relaxed selectively. The objective is not the highest autonomous resolution percentage. It is the highest rate of correct outcomes, and those goals differ.
Runbook coverage depends on collaboration with each pilot team. Cordant can resolve autonomously only where a runbook exists. Increasing coverage means teams must write and validate runbooks for their incident patterns, which takes time. We are building tools to speed authoring and a coverage recommendation feature that identifies the incident types most worth adding.
Two hundred incidents is a useful sample, but it remains small. We are sharing these figures because the pattern appears genuine and worth examining, not because these percentages are settled production benchmarks. The next 200 incidents will add context.