What Can AIOps Actually Automate?
The problem in most operations teams is not too little monitoring, it is too much. One failure produces eighty alerts and an engineer spends the first twenty minutes working out which system actually broke. AIOps correlates those into a single incident and points at the likely cause with the evidence attached — so the time goes into fixing rather than triaging.
Traditional Monitoring vs. AIOps
| Step | Traditional Monitoring | AIOps |
|---|---|---|
| During an incident | Dozens of alerts from every affected system | One incident, with the related alerts grouped |
| Thresholds | Static, so they fire every deployment window | Learned per service, aware of normal cycles |
| Finding the cause | Engineers correlate dashboards by hand | Probable cause ranked, with the evidence shown |
| Recurring issues | Rediscovered each time by whoever is on call | Matched to past incidents and their resolutions |
| Noise | Grows until people mute channels | Suppressed when alerts are downstream of a known cause |
Alert Fatigue Is the Actual Risk
When a channel produces hundreds of alerts a day, engineers stop reading it. That is a rational response to noise and it is also how real incidents get missed — the signal was there, nobody could see it.
Correlation attacks this directly. Eighty alerts from one root cause become one incident, and the alerts that are simply downstream consequences get suppressed rather than paged.
Measure it honestly before and after: alerts per engineer per shift, and what proportion were actionable. Most teams have never counted, and the number is usually worse than anyone expects.
Suggest Remediation, Automate Carefully
Suggesting a fix based on how similar incidents were resolved is safe and immediately useful, particularly for whoever is on call at three in the morning without the context the day team has.
Executing that fix automatically is a different risk. Restarting a service is usually fine; anything touching data, capacity or failover is not. Start with suggestion, automate only the actions whose worst case you have thought through, and keep a clear record of what was done automatically — an unexplained change during an incident is worse than a slow one.
The Reporting Clock Is the Design Driver: NIS2 and CERT-In
For essential and important entities in the EU, NIS2, Directive (EU) 2022/2555, sets a cascade in Article 23(4): an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours carrying an initial severity and impact assessment plus indicators of compromise, and a final report not later than one month after that 72-hour notification is submitted — not one month from the incident, which is the clock teams usually set by mistake. Being a Directive, NIS2 binds through each member state's implementing law rather than directly, so check the local transposition: the clocks are harmonised, the scope thresholds and the filing channel are not. Becoming aware is a timestamp your correlation engine creates, so incident records need a first-detection field you can defend afterwards. Severity has to be scored against the significant-incident test rather than your internal P1/P2 scale, which means the classifier output schema needs a regulatory-severity field and has to start a clock. A correlation system with no notion of the 24-hour boundary quietly consumes it during triage.
India is stricter, in three specific ways. The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, require reportable cyber incidents to reach CERT-In within 6 hours of being noticed — a quarter of the NIS2 early-warning window, so one global runbook cannot run on a single timer. Logs of all ICT systems must be enabled, maintained securely for a rolling 180 days, and maintained within Indian jurisdiction, which is a residency constraint on your observability stack rather than on customer data, and rules out shipping logs only to a foreign-region SIEM. And system clocks must be synchronised to NIC or NPL NTP servers, or to sources traceable to them, which makes cross-system correlation a compliance property rather than a convenience.
Which Models We Would Shortlist for This
Incident context grows unpredictably — a channel, a timeline and log excerpts — so how a provider prices long prompts matters more here than on most workloads. Two of these re-price partway through a long incident and two do not.
Claude Sonnet 5 — 1,000,000 tokens at a flat $3/$15 takes a full incident channel plus log excerpts in one prompt. Flat pricing means growing context does not also grow the rate.
GPT-5.4 — a 1,050,000-token ceiling at $2.50/$15, but everything above 272,000 tokens re-prices to $5/$22.50. A long postmortem timeline crosses that line easily.
GLM-5 — open weights, a published 200,000-token window and 128,000 max output at $1/$3.20 first-party. Because the weights are open, third-party hosts serve the same model at their own rates, so z.ai's price is a ceiling — and self-hosting keeps production logs off a vendor API entirely.
Gemini 2.5 Flash-Lite — $0.10/$0.40 for alert triage and noise suppression at monitoring volume, before anything reaches a model priced for reasoning.
Prices are the providers' own published list rates, not resale or routed rates. Each model page names the source document and the UTC time the figure was checked. Claude Sonnet 5 is quoted at its standard rate; Anthropic's $2/$10 introductory rate runs to 2026-08-31.
Where This Fits
This is one part of our work in AI for Information Technology. See the full set of AI use cases for the equivalent in other industries and functions.
Frequently Asked Questions
How much historical data does it need?
A few months of alert and incident history is usually enough to learn baselines and correlate. The more valuable input is resolved incidents with real notes on what fixed them — most teams have plenty of alert volume and very thin resolution detail, and that is the gap worth closing first. If you operate in India, the CERT-In directions already require 180 days of ICT system logs held within the country, so the retention obligation and the training corpus are usually the same logs.
Will it work with our existing monitoring tools?
It should sit on top of them rather than replace them. AIOps consumes alerts, metrics and logs from what you already run — the whole point is correlating across tools that do not talk to each other. Replacing your monitoring stack is a much bigger project and rarely what actually helps.
Can it predict failures before they happen?
For gradual degradation, often yes — disks filling, memory leaks, latency creeping over days are all detectable well ahead of failure. Sudden failures are largely unpredictable, and vendors implying otherwise are overselling. The reliable value is in correlation and faster diagnosis, not prophecy.
What about false positives from anomaly detection?
Expect them early, especially around deployments, seasonal traffic and scheduled jobs. The system needs to learn your normal cycles, and that takes a few weeks of feedback. Plan for a tuning period rather than judging it in week one — teams that switch it off after a noisy first fortnight never get to the useful part.
Does this reduce headcount?
In our experience it changes what the team does rather than shrinking it. Time moves from triage into reliability work — the improvements that stop incidents recurring, which nobody ever has time for. If your operations team is permanently firefighting, that reclaimed time is worth more than the salary saving.
Count your actionable alert rate before and after — most teams never have.
Get a Free Proof of Concept within weeks.
Let’s talk
Tell us what you’re
trying to build
The first 45-min alignment session — and a small PoC — are free.
Or just say hello or write us an email.