AIOps: fewer alerts, and the right ones

Why adding a monitoring tool solves nothing

Because alert volume is a design problem, not a tooling problem. An extra tool produces extra alerts, on the same events, seen from another angle. Teams end up filtering mentally, and incidents keep being reported by users before monitoring catches them.

The mechanism is well documented: past a certain volume, an alert stops being a signal and becomes background noise. That threshold is reached far sooner than people expect.

The work therefore consists of reducing, not adding. Correlate the events describing one cause, remove those that trigger no action, and surface what has a consequence for a delivered service.

The test is simple and unforgiving: if an alert never triggers an action, it should not exist.

How do you improve the signal-to-noise ratio?

Through correlation, learned thresholds, and a change in the unit of observation. You group events describing a single incident, replace hand-set thresholds with thresholds learned from real behaviour, and monitor delivered services rather than devices.

• Correlation. A failed link produces dozens of events across as many devices. They describe one incident and must surface as one.
• Learned thresholds. A threshold fixed at 80% utilization is arbitrary: on some links that is normal, on others it is already an anomaly. A threshold learned over several weeks accounts for business cycles.
• Service-level monitoring. "The link to site B is saturated" calls for no decision from a management team. "Billing is unusable from site B" does.
• Suppression. The least practised and most productive step. Any alert that has triggered no action in months is removed, or converted into an indicator.

What must automation never decide alone?

Anything not agreed with you in advance. Automated remediation runs within a written scope (which actions, on which devices, under which conditions)and every execution is logged with its trigger, its rule and its outcome. Anything outside that scope requires human validation.

This constraint is not excessive caution: it is an auditability requirement. In the sectors we serve, you must be able to explain after the fact why an action took place, and demonstrate that it fell within an agreed framework.

It also guards against the most expensive failure mode of unbounded automation: the corrective action that worsens the incident. Restarting a service, isolating a device or blocking a flow are useful actions, and destructive at the wrong moment.

We therefore always start with reversible, low-impact remediations, and widen the scope as confidence in the setup is built on evidence.

What data feeds these analyses?

Technical infrastructure data: telemetry, device logs, network flows, configuration state. No personal information enters without explicit contractual framing and a prior privacy impact assessment.

The distinction matters, because infrastructure logs sometimes contain user identifiers, addresses or file names. Treating that content as plain technical data would be a mischaracterization.

Before any deployment we therefore establish what is collected, for what purpose, and for how long. That is also what allows you to answer an auditor without having to reconstruct the information.

Where that processing physically runs raises the same question, and it is the subject of our sovereign AI approach.

Frequently asked questions