State of Enterprise AIOps 2026

The most useful finding in this study is not that AI is capable. It is that enterprise infrastructure fails in the same handful of ways, over and over, in every industry we measured — and that most organisations have never quantified how much of their engineering week that repetition consumes.

1. Method

Two datasets sit behind this paper. The first is an instrumented alert corpus: every alert that reached a NOC queue across production estates in banking, healthcare, manufacturing, telecom, retail, and logistics, captured over eighteen months to March 2026. The corpus came to 2.4 million alerts across roughly 11,000 managed units.

The second is a survey of 400 enterprise IT leaders — CIOs, heads of infrastructure, NOC managers, and SRE leads — conducted between January and March 2026, weighted so that no single industry accounts for more than 22% of responses. Estate sizes ranged from 90 to 4,200 managed units.

• Alerts were normalised by stripping hostnames, timestamps, instance identifiers, and numeric thresholds, then clustered on the residual signature.
• Incidents are deduplicated: a storm of 400 alerts caused by one upstream failure counts as one incident, not four hundred.
• Autonomy rates are measured at day 90 or later, after each deployment had exited observe mode — early-month rates are flattered by easy signatures being automated first.
• Survey responses on time allocation were cross-checked against ticket-system timestamps where the respondent granted access; self-reported triage time was consistently understated by 20–30%.

2. Finding one — the long tail is much shorter than people assume

When 2.4 million alerts are normalised and clustered, they collapse to approximately 180 distinct signatures. The top 25 signatures account for just over 61% of total alert volume. The top 60 account for 82%. This holds with remarkable consistency across industries: a full filesystem behaves identically whether it sits under a core banking system or a warehouse management system.

This matters because a signature that recurs hundreds of times a month has something a novel incident does not: a resolution history. Every previous occurrence carries the diagnostic path an engineer walked, the command they ran, and whether it worked. That is training data in the most literal sense, and it is already sitting in the ticket system.

The eight failure classes

Nearly all L1 volume — and a surprising share of L2 — falls into eight classes. Across all six industries these eight accounted for 84% of deduplicated incident volume.

Each class has a small number of safe, well-understood, reversible remediations. Clearing archive logs after confirming a backup completed. Restarting a stateless service after draining connections. Killing a blocking session after confirming it holds no in-flight commit. These are not creative acts. They are runbooks that engineers execute at 2am while half asleep — which is precisely why they are executed inconsistently.

3. Finding two — the ceiling is governance, not capability

We classified every incident in the corpus against three tests: is the signature known, is a deterministic remediation available, and is that remediation reversible without data loss? An incident had to pass all three to count as technically autonomously resolvable. 74.6% passed. The rate estates actually achieve is lower — and the gap is entirely organisational.

Banking sits lowest at 68% not because banking incidents are harder, but because a larger proportion of policies are deliberately held at approve-then-act: the change advisory process requires a named human on every production change touching systems in regulatory scope. That is a legitimate choice, not a failure. What autonomy buys those estates is not the removal of the human but the removal of the diagnosis and preparation work — the engineer approves a fully-formed action with evidence attached, rather than starting from a red alert at 2am.

Retail peaks at 75% during high-traffic events, which surprises people who assume peak load means more chaos. In practice, peak-event incidents are more repetitive: capacity exhaustion, connection pool saturation, cache pressure, and queue backlog, over and over across a horizontally scaled fleet. Repetition is exactly what policy-driven automation is good at. Off-peak retail settles around 66%, where the incident mix is more varied.

What does predict a high rate

1. 1Standardisation. Estates with a small number of OS builds, consistent agent deployment, and uniform naming conventions score 8 to 11 points higher than heterogeneous estates of the same size.
2. 2Runbook maturity. Teams that already maintain written, tested runbooks convert them to policies in days. Teams relying on tribal knowledge spend the first month writing down what they know — which is valuable work, but it is not automation work.
3. 3Monitoring hygiene. Estates with high false-positive rates depress the measured autonomy rate, because noise alerts are correctly escalated rather than acted upon.

4. Finding three — what automation actually buys back

The commercial conversation around AIOps is dominated by headcount reduction. The data does not support that framing, and the organisations getting the most value are not pursuing it. In the estates we measured, senior engineers spent between 40% and 55% of their week on incidents drawn entirely from the top 25 signatures — work with a written runbook and a known outcome.

The band that moves is L1 triage and routine L2 remediation. What it moves into is problem management — the practice of eliminating recurrence at source — and engineering project work. Both are activities that reduce future incident volume, which is why the effect compounds. An estate that automates its top signatures and then never touches problem management has captured perhaps a third of the available value.

The cost that never appears on a business case

The expensive failure mode of alert fatigue is not wasted hours. It is the genuine incident that arrives in the middle of a storm and receives the same reflexive dismissal as the 400 alerts before it. Reviewing post-incident reports across 14 estates, in 31% of major incidents the first signal had been raised and acknowledged more than 20 minutes before anyone recognised its significance — and in most of those cases, alert volume in the preceding hour sat above the estate’s 90th percentile.

Median acknowledgement time degrades measurably under sustained volume. In the first 30 minutes of a storm it holds near baseline. By 90 minutes it has typically risen 2.5 to 4x, and the rate of alerts closed as “duplicate” without investigation roughly triples. Engineers are not being careless; they are triaging under a load no human sustains.

5. Industry evidence

The aggregate numbers hide the interesting part, which is how differently the same eight failure classes present in different industries. These are drawn from named deployments, anonymised at customer request.

6. The thought process — designing for less human effort, not fewer humans

It is worth being explicit about the reasoning that shaped this product, because it determines which numbers we chased and which we ignored.

The first premise is that the scarce resource in enterprise IT is not compute, licences, or even headcount. It is the attention of the few engineers who genuinely understand the estate. Those people are systematically starved of time by work that does not require their judgement, and the organisation loses twice: once on the salary spent, and once on the problems that never get solved because nobody had a quiet week.

The second premise is that automation which requires trust up front will not get deployed. Every enterprise has a graveyard of scripts that ran once, did something surprising, and were disabled. The path to autonomy is not a better model — it is a mechanism that lets an organisation grant a narrow, revocable, auditable permission and then widen it on evidence. That is why observe mode exists, why policies are signed artefacts with expiry, and why we ship with everything inert.

The third premise is that reducing effort and removing people are different projects, and conflating them poisons adoption. In every deployment where the stated goal was headcount reduction, the engineers who had to author the policies were being asked to automate themselves out of a job. Policy quality suffered, edge cases went undocumented, and the estate stalled at stage two. In deployments framed as “stop being paged for things a script should handle,” the same engineers wrote better policies faster.

“Automation earns trust by being boring. The first hundred actions should be the ones nobody would have thought twice about.”

Arjun Kumar, Chief AI Officer

What we deliberately do not optimise for

• Headline autonomy percentage. It is trivially inflated by choosing a favourable denominator or by counting alert suppression as resolution.
• Breadth of policy library at go-live. A hundred policies activated on day one is a risk profile, not an achievement.
• Novel-incident handling. The 12–16% of genuinely novel incidents is where human engineering value lives, and we design to route it to a human faster, not to guess at it.
• Cross-customer model training. The marginal accuracy gain does not justify pooling hundreds of enterprise infrastructure maps in one place.

7. Adoption barriers, ranked by the people who face them

Survey respondents ranked barriers to adopting autonomous operations. The result is a useful corrective to the industry narrative, which assumes the blocker is model trust.

Model accuracy ranks sixth. The top three are all governance and evidence problems. This is the single most important input into how we build: a system capable of diagnosing a blocking session was never the hard part. Proving to a CISO with an audit obligation that the system will never act outside a policy a human signed — that is the hard part, and it is the part most of this market is under-investing in.

8. Run this study on your own estate

You should not take our numbers on faith, and the exercise is genuinely worth doing even if you never buy anything. It takes a competent engineer about three days.

1. 1Export 90 days of alerts from your monitoring platform. Normalise out host, time, instance identifiers, and numeric thresholds.
2. 2Cluster on the residual signature and rank by frequency. Stop where the cumulative curve reaches 80% — that is usually far fewer signatures than expected.
3. 3For each signature in that band, ask the owning engineer two questions: is there a standard runbook, and is the action reversible without data loss?
4. 4The proportion answering yes to both is your realistic autonomy ceiling — before any AI is involved, and independent of any vendor.
5. 5Separately, sample 40 closed tickets from the top band and measure time-to-close from timestamps, not from self-report. Multiply by annual frequency. That is your current cost of repetition.

Most estates we have run this with land between 60% and 78%. If your number is materially lower, it usually indicates alert configuration problems rather than an unusual environment — and fixing those is worth more than any automation layer you could buy.

References & further reading

1. [1]NIST AI Risk Management Framework (AI RMF 1.0) National Institute of Standards and Technology, January 2023
2. [2]ISO/IEC 42001:2023 — Artificial intelligence management systems International Organization for Standardization
3. [3]Site Reliability Engineering — Chapter 5, “Eliminating Toil” Beyer, Jones, Petoff & Murphy, O’Reilly Media, 2016
4. [4]ITIL 4 — Incident Management and Problem Management practices AXELOS / PeopleCert
5. [5]Annual Outage Analysis Uptime Institute, published annually
6. [6]AAQUILIX instrumented alert corpus, Oct 2024 – Mar 2026Internal — 2.4M alerts, ~11,000 managed units, six industries