Anomaly detection with seasonal baselines and causal AI

What is anomaly detection in observability?

Anomaly detection is the automatic identification of behaviour that deviates from what is normal for a system. In observability this means spotting unusual values in metrics, logs and traces, such as a latency increase on one endpoint, a new error pattern in logs or a drop in completed checkouts, without someone having defined a fixed threshold for each of them in advance.

Static thresholds work for a few well-understood signals, like disk usage above 90 percent. They fail for most others. Request rates follow daily and weekly cycles, batch jobs create predictable spikes, and every service has a different "normal". A threshold that catches problems at 3 a.m. fires constantly at noon; a threshold that is quiet at noon misses a real problem at night. Anomaly detection replaces these guesses with learned baselines.

Why anomaly detection matters

Modern systems produce millions of time series. No team can hand-tune alerts for all of them, so in practice most signals are not monitored at all, and the ones that are monitored generate noise. Both lead to the same outcome: incidents are discovered late, often by customers, and on-call engineers learn to ignore alerts.

Good anomaly detection changes that balance. It covers every service and endpoint by default, alerts on deviations that are actually unusual and catches slow degradations that never cross a hard limit. Combined with correlation, it turns a storm of symptoms into a single problem, which is the precondition for a short mean time to resolve.

Seasonal baselines and the signals that matter

A baseline describes the expected range of a signal at a given time. Obseria Intelligence learns baselines with daily and weekly seasonality, so a Monday 9 a.m. peak is compared to previous Monday mornings, not to the overall average. Baselines adapt continuously; when a release permanently changes behaviour, the model follows instead of alerting forever.

Signals that benefit most from baselining include:

• Golden signals per service and endpoint: latency, traffic, errors and saturation.
• Log patterns: new or suddenly frequent message templates, grouped automatically.
• Infrastructure metrics such as CPU throttling, memory growth, queue depth and connection pool usage.
• Frontend experience from RUM, for example Core Web Vitals or JavaScript error rates per region.
• Business KPIs like orders, sign-ups or payments, where a drop is often the first visible symptom.

How Obseria detects and explains anomalies

Obseria Intelligence combines causal, predictive and generative AI. Detection is only the first step. Each anomaly is placed on the dependency graph that Obseria TopoGraph builds automatically from traces, agents and cloud APIs. If a database becomes slow and five services that call it show higher latency, you get one problem with the database as the probable cause, not six separate alerts.

Deployments, feature flag changes and configuration events are part of the same model. An anomaly that starts two minutes after a release is linked to that release. From there, an agentic investigation can run: it queries the relevant traces, logs and metrics, tests hypotheses and returns a root cause together with the chain of evidence it used. You can open every query and verify it yourself, for example:

fetch spans | filter service == "checkout" and duration > 2s | summarize count(), by:{endpoint, version}

Investigations consume Intelligence agent credits; baselining and detection on your ingested data are included.

Best practices for anomaly detection

1. Start with user-facing signals. Prioritise endpoint latency, error rate and key business KPIs before infrastructure details.
2. Keep static thresholds for hard limits. Disk full or certificate expiry are better served by fixed rules.
3. Send deployment events. Change context dramatically improves correlation and reduces investigation time.
4. Tune sensitivity, do not disable. If a service is noisy, lower its sensitivity instead of turning detection off.
5. Route problems, not anomalies. Page on correlated problems and leave individual anomalies as context on dashboards.