Every AIOps pitch opens the same way: your systems detect their own failures, diagnose the cause, and repair themselves before anyone is paged. It is a genuinely appealing picture, and the underlying technology is real.
Then look at where organisations actually are. Deloitte's maturity survey puts 55% of enterprises at Level 1 or 2 — still running reactive operations with basic tooling. Only 17% have reached Levels 4 or 5, where autonomous remediation produces measurable business value.
Forrester's AIOps research lead has been blunt about what happens next: 60% of enterprises are expected to fail at AIOps this year for want of a maturity model.
That failure rate is not a technology problem. It is what happens when you buy automation for an operation that has never written down how it fixes things.
Self-healing infrastructure detects a fault, determines the cause, and executes a remediation without human intervention — restarting a failed service, scaling a saturated resource, rolling back a bad deploy, or failing over to a healthy replica. AIOps is the broader discipline: applying machine learning to operational telemetry for detection, correlation, and root cause analysis. Self-healing is the subset where the system is also permitted to act.
Start With the Alerts, Not the AI
A typical DevOps team receives more than 2,000 alerts a week. Around 3% require any action at all. Security operations teams see it worse — roughly 4,484 alerts daily, with about 67% ignored purely because of volume.
Grafana Labs research identifies alert fatigue as the single largest obstacle to faster incident response. Not tooling. Not headcount. Noise.
This matters more than it first appears, because AIOps trained on your existing alerts inherits your existing noise. If 97% of your alerts are meaningless, a model that learns from them learns to treat meaningless signals as normal — and automated remediation triggered by noise produces automated noise, executed faster and with less oversight than before.
Buying an AIOps platform before fixing alert quality is the most common and most expensive error in this space. The platform will happily correlate your noise into higher-confidence noise. Alert hygiene is unglamorous, takes about three weeks, and does more for MTTR than the first six months of any AIOps deployment.
What the Benchmarks Actually Support
The performance claims in this category vary wildly depending on who is publishing them. Here is what holds up across independent sources rather than vendor case studies:
Splunk's research puts unplanned outage losses across the Global 2000 at around $300 million annually, with 43% of those outages originating in network or IT environment failures.
The headline numbers you will see quoted — BT Group taking mean time to remediation from two hours to 85 seconds, or 87% MTTR reductions at carrier scale — are real, but they come from organisations already operating at high maturity with dedicated platform teams. Treat the 40–60% range as your planning figure. Anything beyond that is what you might earn in year three.
Where You Actually Are
There is a simple diagnostic that tells you your maturity level without a consulting engagement. How is your MTTR measured?
| Level | MTTR measured in | What is true at this level | What to do next |
|---|---|---|---|
| Level 1–2 | Hours | Reactive. Alerts fire, humans investigate from scratch each time. Runbooks are tribal knowledge or out of date. | Alert hygiene and written runbooks. Not AIOps. |
| Level 3 | Tens of minutes | Correlation works. Related alerts group into incidents. Root cause suggestions are usually right. Humans still execute the fix. | Automate the three most frequent remediations, with approval gates. |
| Level 4–5 | Minutes or seconds | Autonomous remediation for known incident classes. Humans handle novel failures and approve high-risk actions. | Expand incident classes. Tighten blast radius controls. |
Roughly 55% of organisations are in the first row. If that is you, the useful next step is not a platform purchase — it is writing down what your team already does when things break.
The Prerequisite Nobody Sells You
Here is the constraint that determines whether an AIOps investment pays back:
You cannot automate a remediation you have never performed by hand.
Self-healing infrastructure is, mechanically, a set of codified runbooks with the confidence to execute them unattended. If your team's recovery procedures live in three senior engineers' heads and a Slack thread from last March, there is nothing for the automation to learn from and nothing for it to run.
- · Tool bought before alert quality addressed
- · No written runbooks to codify
- · Model trained on 97% noise
- · No blast radius limits on automated actions
- · Nobody owns the automation when it misfires
- · Success measured by alerts suppressed, not incidents resolved
- · Alert hygiene done before any automation
- · Top incident classes documented and repeatable
- · Automation starts with approval gates, then earns autonomy
- · Every automated action is scoped and reversible
- · A named engineer owns each automated remediation
- · Success measured in MTTR and incident recurrence
What a Self-Healing Layer Contains
The remediations worth automating first are the ones that are frequent, low-risk and deterministic: restarting a hung service, scaling a saturated resource group, clearing a full disk of known-safe temporary files, rotating an expired certificate, failing over to a healthy replica. These are typically a large share of overnight pages and almost none of the genuinely hard incidents. Automate the boring ones and give your engineers their nights back — that alone justifies the work.
A Realistic Sequence
Audit your alerts before buying anything
Export three months of alerts. For each type, count how many led to an action. Delete or downgrade anything with a near-zero action rate. Teams routinely remove 60–80% of alert rules in this exercise, and MTTR improves before a single automation is written.
Week 1–3Rank incidents by frequency, not severity
The incident that woke someone forty times last quarter is a better automation candidate than the one catastrophic outage. Frequency is where the recovered engineering hours are, and where you build the confidence to automate riskier classes later.
Week 3Write and test the top three runbooks
As code, in version control, tested in a non-production environment. If your team cannot agree on the correct remediation for an incident class, that disagreement is the real finding — and it needs resolving before any automation runs it.
Week 4–6Run them with a human in the loop
The automation proposes, an engineer approves. Track how often the proposal was correct. Anything below roughly 95% accuracy is not ready to run unattended, regardless of how confident the dashboard looks.
Week 6–10Release the approval gate, one class at a time
Only for remediations with a demonstrated track record, scoped blast radius and a working rollback. One incident class at a time, each with a named owner. Never a bulk switch to autonomous mode.
Week 10+Measure recurrence, not just resolution
An automation that restarts a failing service every twenty minutes has excellent MTTR and is hiding a defect. Track incident recurrence alongside MTTR, or you will automate away the symptom and keep the cause indefinitely.
OngoingFrequently Asked Questions
Not Sure Which Level You're At?
We do AWS architecture, DevOps, incident automation and DR/BCP for production systems. Book a free 30-minute call — we'll look at your alerts and tell you honestly whether AIOps is your next step or a distraction.