Strip the buzzword and a real thing remains: machines are genuinely better than humans at learning "normal" and noticing deviation at scale. Here is the honest map of where that helps — and where the marketing outruns it.
AI helps monitoring in four proven ways: learning each component's normal behaviour instead of relying on hand-set thresholds, detecting anomalies and trends within it, correlating related signals into single findings, and grouping duplicate events to cut noise. None of this requires — or is improved by — mystique: most of it is well-understood statistics applied continuously at a scale no human team can match. The honest boundaries matter as much as the capabilities, because monitoring is a domain where overclaiming ("AI predicts all outages", "AI finds root causes") produces tools people learn to ignore.
The oldest monitoring problem is thresholds. "Alert if latency > 500ms" is wrong for the endpoint whose normal is 900ms and useless for the one whose normal is 80ms; multiply by every endpoint, hour and seasonality, and hand-maintained thresholds collapse under their own falseness. The machine-learning answer — in the modest, accurate sense of learning from data — is to compute each monitor's own baseline continuously: latency percentiles, error rates, volumes, over a trailing window, excluding the period being judged.
This is statistics, not sorcery, and that is the point: it is reliable. A system that knows p95 for /api/orders has been 420ms for two weeks can say "1,400ms is 3.3× normal" with a straight face. Every capability that follows stands on this one, and its quality depends on data discipline — enough history, honest exclusion windows, per-monitor granularity — the baseline mechanics matter more than the algorithm's brand name.
With baselines in place, detection becomes deviation arithmetic — and machines excel at running it everywhere, always:
The catch — the honest catch — is the false-positive economy. Statistical deviations vastly outnumber real problems, so raw anomaly detection produces noise, and noisy tools get muted. Which is why detection alone is not the product; the next capability is.
The intelligence users actually feel is synthesis:
Where current capability ends, stated plainly:
Buyer's checklist, compressed: learned from what data, over what window? What evidence accompanies each finding? What is the false-positive experience — and does the tool measure its own hit rate? Vague answers to those three questions predict the tool's Slack channel getting muted within a quarter. The proactive shift only pays if the warnings stay credible.
| Proven capability 1 | Learned baselines per monitor — replacing unmaintainable hand-set thresholds |
|---|---|
| Proven capability 2 | Anomaly + trend detection on baselines: point deviations, monotonic drifts, pattern breaks |
| Proven capability 3 | Correlation and grouping: one cause → one warning; duplicates → counters; deploys as context |
| Boundary 1 | Prediction covers deterioration-preceded failures only — not no-prodrome failures |
| Boundary 2 | Telemetry yields suspects with evidence, not root-cause verdicts |
| Trust mechanics | Risk and confidence separate, evidence listed, misses admitted via self-resolution |
| Buyer's questions | Learned from what? Evidenced how? Wrong how often — and does it say so? |
By learning each monitored component's normal behaviour — latency percentiles, error rates, traffic patterns over a trailing window — and continuously comparing the present against it. Deviations (an error rate many times normal) and trends (latency rising steadily for hours) are flagged while the application still works, because deterioration usually precedes failure by hours.
The foundational capabilities — baselines, deviation detection, trend analysis, fingerprint grouping — are well-understood statistics applied continuously at scale, and that is a strength: they are explainable and reliable. The accurate sense of "learning" is that the system derives normal from data rather than from hand-set thresholds. Treat unexplained "AI magic" claims as marketing until shown the evidence trail.
Partially, and honest tools say so. Failures preceded by measurable deterioration — latency drift, error creep, resource exhaustion, certificate expiry — are genuinely predictable with useful lead time. Failures with no prodrome, like sudden infrastructure loss or instantly-fatal config changes, are not. A large share of real incidents falls in the predictable class, which is why the capability matters despite its limits.
It can narrow the search dramatically — which endpoint, since when, correlated with which deploy and which dependency's status — and present ranked suspects with evidence. The actual mechanism typically lives in code and logs, where humans confirm. Be wary of tools that announce root causes as verdicts; correlation presented as certainty is how monitoring loses trust.
Risk expresses how bad the evidence looks — how far outside normal, how many signals agree. Confidence expresses how much evidence there is — how much history backs the baseline, how much current data supports the reading. Keeping them separate matters: 78% risk on two hours of history is a different claim from 78% on two weeks, and collapsing them into one score hides exactly what a responder needs to weigh.
Ask three questions. What does it learn from, and how much history does it need? What evidence accompanies each finding — can you see why it fired? And how does it handle being wrong — does it admit self-resolved warnings and measure its own hit rate? Confident vagueness on any of the three predicts alert fatigue and eventual muting.
Merik's early-warning engine is built on the honest three: baselines (p50/p95/p99 and error rate per monitor, 14-day window, current hour excluded), deviation and trend detection with ratio-plus-absolute guards, and correlation — every signal for an asset folded into at most one warning, with deploys from GitHub/Vercel webhooks shown as temporal context and vendor outages suppressing the pile-on. Grouping runs the same way on browser errors: fingerprints and counters, not forty thousand rows.
The boundaries are respected in the product's own language: risk and confidence are separate numbers, the evidence list is always attached, warnings that fizzle resolve themselves and say so, and warnings that come true link to the incident they predicted — so the hit rate is a number you can check, not a claim you have to take. No verdicts, no mystique: measured normal, honest deviation, and one credible warning at a time.
One tells you it broke; the other tells you it's breaking. That word is worth hours.
Capture, group and alert on the errors in your users' consoles — without drowning in noise.
Five causes, six rules, and the two numbers that say whether your alerts are worth reading.