How AI root-cause analysis works

Ask an experienced on-call engineer how they find the root cause of an incident, and the honest answer is usually a sequence of habits: check what deployed in the last hour, check the error rate graph, check if a dependency is having a bad day, check Slack for anyone else reporting something odd. None of those steps are individually hard. Doing all of them under pressure, quickly and in the right order, is what actually takes practice — and what an AI system can do consistently, every time, in seconds.

VeloOps root-cause analysis starts from the same signal a human would: an anomaly, meaning a metric or log pattern that has moved meaningfully away from a service’s learned baseline. That baseline is not a static threshold — it is built from the service’s own history, so a checkout API at 2x its normal Tuesday traffic is not an anomaly, but the same traffic pattern with triple the error rate is.

Once an anomaly is flagged, the correlation engine pulls in everything that changed around the same window: deploys to the affected service and its immediate dependencies, infrastructure changes such as scaling events or configuration updates, and any related anomalies in upstream or downstream services from the dependency graph. This is the step that used to require a human opening four different tools.

The correlated evidence is then passed to a hosted foundation model, with a structured prompt asking it to rank plausible root causes and explain its reasoning against the evidence — not just describe the symptom. A summary like "error rate on checkout-api rose 40x within 90 seconds of the 14:02 deploy, which changed the payment-gateway client timeout from 5s to 500ms" is more useful than "checkout-api is failing," because it points directly at the fix.

Confidence matters as much as the explanation itself. VeloOps ranks candidate causes and shows the evidence behind each one, rather than presenting a single guess as fact. When the correlated evidence is thin — a genuinely novel failure mode, or several plausible causes with similar signal strength — the summary says so, and the incident timeline is there for a human to reason through the rest.

The result is not meant to replace engineering judgement. It is meant to remove the twenty minutes of manual correlation that happens before judgement can even start, so the person who gets paged spends their time deciding what to do about the problem, not figuring out what the problem is.