Anomalies in Time Series: Spikes, Level Shifts, and Seasonal Surprises

An anomaly is a deviation from an expectation — which means detection quality depends entirely on how good the expectation is. Thresholding the raw values ("flag anything above 3 standard deviations") works only on flat, static series. Business time series have trends, cycles and level shifts, so the expectation must be built from the series itself. The practical method is: model the normal, then measure the residual.

Build the Expectation

For each point, construct a "normal" reference from its own history:

1. Remove the trend with a moving average or a fitted line.
2. Remove the seasonality (see seasonality detection) so a Monday is compared with Mondays, not with the week's average.
3. Compute the residual — observed minus expected — and standardize it against the residual's own spread (a rolling standard deviation, not the global one).

What remains is a series where "normal noise" hovers near zero and genuine anomalies stand out. A z-score threshold of 3 on these residuals catches far fewer false positives than the same threshold on raw values, because it has already absorbed the pattern.

Distinguish the Three Kinds

Once flagged, classify the anomaly — the three types imply different actions:

• Point anomalies (spikes and dips). A single period far from expectation, neighbours normal. Actions: verify the record, check for a one-off event, re-run the number. A spike in an otherwise calm series is usually a data or reporting event, not a change in the business.
• Contextual anomalies. A value that is perfectly normal in isolation but wrong for its context — high traffic on a Sunday, zero sales on a Friday. These are the ones pure thresholds miss. Seasonal context is the whole game here; without it you will re-alert on the same Sunday every week.
• Level shifts. A sustained jump (or drop) that persists across many periods. A level shift is not a spike — no single point is extreme. It is detected by comparing rolling means before and after the candidate break point. Actions: treat as a regime change — new customer, new pricing, new competitor. Rebuild the baseline; from here on, the old "normal" is history.

Practical Guardrails

A few rules keep anomaly detection useful instead of noisy:

• Alert on the classification, not the flag. "Spike in revenue — verify entry" and "level shift in revenue — investigate strategy" are different messages for different people. Send the right one.
• Suppress repeats. Once a level shift is confirmed, stop alerting on it. The system should learn the new baseline, or every report becomes a wall of noise.
• Review the detector when it stops firing. A detector that goes quiet for months is usually broken, not perfect — data pipelines change shape and the model drifts with them.

Client-side tools can run all of this — moving averages, rolling z-scores, break detection — over a few thousand rows in milliseconds. The KPI Master signal board does exactly this per numeric column, which is why its anomaly flags carry context: what kind of anomaly, which period, and how far outside the expectation.