Live demo

14 series in. 4 alerts out.

An inference fleet of forty H100 pools, 60 days, 14 series. On day 43 a driver rollout reached one pool and stopped there. Uptime stayed at 99.94%, request volume kept its weekly shape, and the fleet token rate never moved. Find the pool.

Every number on this page is computed in your browser right now, by the same CUSUM and Bayesian changepoint code that runs in production. Nothing here is a screenshot.

The comparison that matters

Against the rule most teams actually ship

The standard configuration is a percentage or sigma threshold against a trailing mean, evaluated per metric. Run it over the exact same 14 series and count what lands in the channel.

Naive rule
50
alerts sent · alert if |Δ| > 2.5σ vs 7-day mean
Of those, false
28
fired before anything was wrong
This engine
4
alerts sent, all correct
Noise reduction
92%
fewer messages, same catch

The false-alarm count is not a judgement call. The incident was injected at a known index, so every naive alert before that index is wrong by construction.

What the engine found

Detection run

Detection run4 alerts14 series tested · 4 fired · 0 suppressed by BH at FDR=0.05
MetricTrendBaselineNowChangeConfidenceMethod
Thermal throttle events
pool=a3-h100-04
35.07183.94+425%99.9%CUSUM
Cost per million tokens
pool=a3-h100-04
$2.84$3.88+36.9%99.9%CUSUM
Tokens per second
pool=a3-h100-04
4187.4833023.752−27.8%99.9%CUSUM
HBM bandwidth utilisation
pool=a3-h100-04
71.2%51.6%−27.5%99.9%CUSUM

Show your work

Thermal throttle events · pool=a3-h100-04

Baseline
35.07
After changepoint
183.94
Change
+425%
Confidence
99.9%
CUSUM (Page 1954)
The series60 daysdashed line = baseline mean · red = detected changepoint
10.34122.50234.66changepointJun 29Aug 27
The CUSUM accumulatorsmall deviations stack slowly; a real shift stacks fast
h = 0.705 (decision boundary)4.410

Baseline mean μ = 0.0024 and σ = 0.1761, both computed from the first two thirds of the day-over-day percentage changes. The slack k = 0.0881 is half a sigma, and the decision boundary h = 0.7046 is four. The accumulator runs on percentage changes rather than raw levels so a healthy growing series cannot drift across the boundary on its own.

What the naive rule did on this same series

alert if |Δ| > 2.5σ vs 7-day mean fired 3 times across this one metric, including 2 before anything was actually wrong. The statistical pipeline sent one message, on the day the regime actually changed.

What lands in Slack

One message, with the work already done

S
SiliconAPP#eng-alerts
🔴 Thermal throttle events jumped +425%pool=a3-h100-04
Baseline
35.07
Now
183.94
Confidence
99.9%
Started
Aug 11
Fleet
inference-prod (40 pools)
Pool
a3-h100-04
Change
driver 550.90 → 555.42
Rolled
Aug 11, 03:10 UTC
Likely cause · The changepoint lands the night driver 555.42 reached pool a3-h100-04 and no other pool. Throttle events rose first, bandwidth utilisation and token rate followed within a day, and cost per million tokens rose because the pool bills the same hourly rate for less work. Every node in the pool still reports healthy and stayed in rotation the whole time, which is why liveness checks never fired.
  1. 1.Roll a3-h100-04 back to driver 550.90 and hold it for 48 hours.
  2. 2.Compare per-node throttle counts inside the pool to separate a fleet-level driver issue from two bad cards.
  3. 3.Check the rack inlet temperature log for Aug 11 before blaming the driver.
AcknowledgeFalse positiveCUSUM · q < 0.0001 · BH-corrected

The written cause is generated only after the statistics confirm the change. The model never decides whether something is an anomaly — it explains one that has already been established. Getting that order backwards is how these products hallucinate.