Flag anomalies in a sensor series with a rolling z-score and explain where it fails.

How to answer

The second clause is the real question: write a correct detector fast, then spend the time on where it breaks.

1. Ask what an anomaly costs. Who is paged, and which hurts more: a false alarm or a missed fault.
2. Define it precisely. A reading’s z-score is its signed difference from the mean of the previous w readings, divided by their standard deviation, so a drop and a rise can have different thresholds. Say “previous”: including the current reading lets a spike inflate its own denominator, and with w = 10 and the sample standard deviation it scores at most 9 / sqrt(10) ≈ 2.85, so a threshold of 3 never fires.
3. Handle the edges and the arithmetic. Emit nothing before the window fills. Floor the standard deviation at the sensor’s resolution: a flat signal divides by zero, and a nearly flat one alarms on every wiggle. A running sum of squares cancels catastrophically when readings are large and the spread small; use Welford-style updates.
4. Decide what the baseline learns. Excluding flagged readings stops a sustained fault from becoming normal. Say the cost: a real level shift, like a product changeover, is then flagged forever. Accept the new level after a run of flags, raising one “level changed” event, or use the median and the median absolute deviation (times 1.4826), which follow a shift once it fills half the window.
5. Then list where it fails. Slow drift, which the window follows. Daily cycles, which it lags. Heavy tails, where a threshold says nothing about false alarm rates. Irregular timestamps, which need a time-based window. A stuck sensor, which needs a flatline check.

Close with alert shaping. Paging on k of the last n flags costs you the isolated spike, the thing a z-score does best, so record those instead.