Live demo

16 series in. 4 alerts out.

A mid-size manufacturer, 60 days of goods receipts, 16 series across four suppliers. On day 39 one supplier’s lead-time variance opened up. On day 44 the mean followed. The all-supplier on-time rate in the QBR deck never moved. Find the supplier, and note which of its two series went first.

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 16 series and count what lands in the channel.

Naive rule
66
alerts sent · alert if |Δ| > 15% vs 7-day mean
Of those, false
33
fired before anything was wrong
This engine
4
alerts sent, all correct
Noise reduction
94%
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 alerts16 series tested · 4 fired · 0 suppressed by BH at FDR=0.05
MetricTrendBaselineNowChangeConfidenceMethod
Lead-time variance
supplier=Kestrel Machining
4.34311.001+153%99.9%CUSUM
Actual lead time
supplier=Kestrel Machining
18.51326.968+45.7%99.9%CUSUM
Incoming defect rate
supplier=Kestrel Machining
1.34%3.85%+186%99.9%CUSUM
On-time delivery rate
supplier=Kestrel Machining
94.3%75.3%−20.2%99.9%CUSUM

Show your work

Lead-time variance · supplier=Kestrel Machining

Baseline
4.343
After changepoint
11.001
Change
+153%
Confidence
99.9%
CUSUM (Page 1954)
The series60 daysdashed line = baseline mean · red = detected changepoint
2.4597.43412.410changepointJun 29Aug 27
The CUSUM accumulatorsmall deviations stack slowly; a real shift stacks fast
h = 0.612 (decision boundary)0.770

Baseline mean μ = 0.0197 and σ = 0.1530, both computed from the first two thirds of the day-over-day percentage changes. The slack k = 0.0765 is half a sigma, and the decision boundary h = 0.6121 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 |Δ| > 15% vs 7-day mean fired 10 times across this one metric, including 3 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

L
Lead TimeAPP#eng-alerts
🔴 Lead-time variance jumped +153%supplier=Kestrel Machining
Baseline
4.343
Now
11.001
Confidence
99.9%
Started
Aug 9
Supplier
Kestrel Machining
Promised
18 days
Variance flagged
Aug 9
Mean flagged
Aug 13
Likely cause · Lead-time variance on Kestrel Machining broke first, flagged Aug 9, while mean lead time was still inside its normal range. The mean followed on Aug 13, defect rate roughly tripled, and on-time delivery fell about twenty percent. The four-day gap is the usable part: a supplier under strain becomes inconsistent before it becomes late, so the spread is the earlier signal. Nothing moved on the other three suppliers, and the all-supplier on-time rate never left its band because this supplier is a small share of order lines.
  1. 1.Call Kestrel before the next release: ask what changed on the line in the week to Aug 9.
  2. 2.Re-plan safety stock on Kestrel parts against the new lead-time distribution, not the promised 18 days.
  3. 3.Pull incoming inspection records for Kestrel lots received after Aug 13.
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.