The Analytics page combines two related surfaces: Anomalies (statistical deviations from a metric’s normal behaviour) and Capacity (linear forecasts of when disk, memory, or connections will run out). One entry, two tabs.

Open it from the sidebar under Monitoring → Analytics, or at /anomalies.

What you see

Header KPIs across both tabs:

• Active anomalies on the fleet.
• Critical — anomalies with the highest severity.
• Warning — mid-severity anomalies.
• Resolved (24 h) — anomalies that returned to normal today.

The Anomalies tab lists every detected event:

• Server and metric — e.g. web-2 · cpu_usage.
• Detected at — when the deviation crossed the threshold.
• Baseline vs observed — what “normal” looked like and what we saw.
• Severity — warning or critical.
• Status — active or resolved, with resolution time.

Filter by severity, status, or metric.

Click through for the event detail: the metric chart with the anomaly band overlaid, a recent history of similar anomalies for the same server and metric, and the raw values.

The Capacity tab lists every active forecast — see the Capacity page for the full breakdown.

What you can do

Anomalies are read-only: they are surfaced by the detection engine, and they resolve automatically when the metric returns to its normal range. From an anomaly you can:

• Open the server to investigate the root cause.
• Route to an alert rule — go to Alert Rules and add an anomaly-source rule to get paged next time.
• Suppress during maintenance — anomaly alerts respect Maintenance Windows automatically.

How it works

Every server metric HostAtlas records — CPU, RAM, disk, load, network, connection counts, plugin data — is fed through a rolling baseline calculation. The baseline captures both the average and the typical spread over a recent window.

An anomaly is raised when the observed value deviates far enough from the baseline to be statistically significant given the metric’s own noise. The result:

• Warning — noticeable deviation. Worth a look; not urgent.
• Critical — large deviation. Something structural changed.

The event resolves automatically when the metric returns to a normal range.

Because baselines are per-metric per-server, an anomaly on a database host that always sits at 5 % CPU fires very differently from one on a batch node that spends its life at 95 %. There is no fleet-wide threshold to tune.

Note

Anomaly detection surfaces “this is weird” — it is not a replacement for hard thresholds like “disk is 95 % full”. Use metric-based alerts for the crisp yes/no cases and anomaly alerts for the softer “something changed” ones. They are complementary.

Notifications

Route anomalies to a notification channel by adding an alert rule under Alerts with source Anomaly. You can scope by severity, metric, and server group.

Related

• Capacity — the forecasting counterpart, sharing this Analytics umbrella.
• Alerts — route anomaly events to notification channels.
• Forensic — time-travel view that overlays anomaly bands on the past.
• Discovery Health — sibling insight surface for discovery gaps.