Why AIOps failed, and what to demand instead

AIOps failed for two reasons, not twenty. The correlation tools of the last decade clustered alerts instead of explaining causation, and they arrived as a platform that you then had to staff. If you ran one of those projects and it stalled, that is not a reason to avoid the category. It is the best possible starting point for demanding something better.

What did AIOps actually promise?

The pitch, roughly a decade ago, was that machine learning applied to your alert stream would cut noise, surface the incidents that mattered and eventually tell you why things broke. The first part was true. Legacy AIOps correlation tools are genuinely good at taking four hundred alerts from six monitoring systems and telling you they are one incident. That is real value, and if you have one deployed, keep it.

The second and third parts never arrived. Knowing that forty alerts belong together does not tell you which deployment, configuration change or cloud-provider event caused them. It does not tell you which team owns the failing service in an estate where the CMDB has been stale since the last acquisition. And it does not write the root cause document that your customer, your regulator or your problem-review board is waiting on. A senior engineer still did that at 11pm, from a Slack thread, four days later.

Why is alert correlation not root cause analysis?

Because they answer different questions. Correlation asks “which of these signals are related?” Root cause analysis asks “what happened, in what order, because of what, and how do we know?” The gap between them is where the engineering hours go.

Every row below the first is work that correlation left to a human. That is the honest reason so many programmes were declared a success at go-live and quietly abandoned eighteen months later: the noise went down and the RCA workload did not.

Why did the platform model make it worse?

The second failure was commercial, not technical. AIOps was sold as software you install and operate. That meant somebody had to own the model tuning, maintain the connectors when a monitoring vendor changed an API, keep the topology import running, and train each new on-call cohort on how to read the console. In most organisations that “somebody” was a platform team with a roadmap of its own, and the AIOps work was the first thing dropped when a quarter got busy.

So the tool degraded. Correlation rules drifted, integrations broke silently, and within two years the console was one more tab that nobody trusted. The vendor was paid for seats and hosts whether or not an RCA ever got written. Nothing in the contract said an outcome had to arrive.

We have written about the structural comparison in more detail on Onepane vs legacy AIOps. The short version is that the category sold clustering and a console, and what operations leaders needed was causation and a document.

Why is a failed AIOps project an asset?

This sounds contrarian and is not. If your organisation already ran an AIOps programme that under-delivered, three things are true that a greenfield buyer would envy.

• The pain is proven. Someone senior has already stood in front of a budget committee and explained that manual investigation across five tools is too slow and too expensive. You do not have to make that case again.
• The budget line exists. A tooling or services line was created for this problem. Renewing it against a different deliverable is far easier than opening a new one.
• You have an accuracy spec. Ask your team what specifically the old tool got wrong. False groupings, missed changes, wrong owners, unreadable output. Those answers become the acceptance criteria and the scoring rubric for anything you evaluate next.

The mistake is to conclude “we tried automation for incidents and it does not work.” The accurate conclusion is “we tried alert clustering and it did not produce root cause.” Those are very different lessons.

What should you demand instead?

Whatever you evaluate next, whether you build it, buy software, or contract a service, hold it to the things the last generation could not do. Five demands, in order of how often they get skipped.

1. Causation with evidence, not clusters. Every claim in the output must link to the specific telemetry, log line or change record that supports it. If the answer is prose without an evidence index, it is an opinion, and an auditor will treat it as one. See what a full evidence pack looks like.
2. Change attribution. Most outages are caused by change. The output must state what changed, with the diff, and how that change reached the symptom through the topology. Position this strictly as “what changed”, never as blame, or the tool creates enemies inside your own organisation.
3. Ownership resolution. In a ten-thousand-resource estate, “who owns this service” is the real bottleneck. Demand a live service-and-ownership map that does not depend on your CMDB being right.
4. A document, not a console. The deliverable is something a customer, a regulator and a problem-review board will all accept. For B2B software companies that usually means a sanitised customer-facing RCA as well as the internal report.
5. An SLA with teeth. Time to RCA against a committed window, an acceptance rate, an abstention rate, and credits when the window is missed. If nobody is contractually answerable for the RCA arriving, you have bought a platform again. Benchmarks for what a reasonable window looks like are on our RCA SLA page.

There is a sixth demand that regulated buyers add: it must run inside your own perimeter, on the observability you already own. A tool that needs your logs shipped to a vendor cloud, or to a third-party model provider, does not clear a bank’s security review regardless of how good the output is. That is a deployment question rather than a capability question, and we cover it on deploy in your VPC.

How do you evaluate without repeating the mistake?

Do not watch a demo. Demos are where the last generation won. Instead, take your last ninety days of Sev1 tickets, the ones your team already wrote RCAs for by hand, and ask the vendor to produce their root cause for each one blind. Score accuracy against what your engineers actually found, and score time-to-cause against how long it took them. Note where the vendor abstains rather than guesses; that behaviour is worth more than a marginally higher hit rate.

That is the evaluation we run, and it is the only one we think is fair to a team that has already been burnt once. If a replacement cannot beat the human RCA on your own history, it should not get the budget line. Read how the service works, or send us your last 90 days and see what we would have found.