The 9 ML Anomaly Detection Methods ThresholdIQ Uses — Explained in Plain English

A Z-score answers one question: "How far is this value from normal, measured in standard deviations?" A Z-score of 0 means perfectly average. A Z-score of 3 means three standard deviations above average — unusual for any distribution. Most single-metric alert systems use one Z-score window. ThresholdIQ runs four windows in parallel: 50 points (short-term), 100 points (mid-term), 200 points (long-term), and 500 points (very long-term). Each window has its own rolling mean and standard deviation.

The number of windows simultaneously breached maps directly to severity level:

• W50 breach only → Warning
• W50 + W100 both breached → Critical
• W50 + W100 + W200 all breached → Emergency

EWMA (Exponentially Weighted Moving Average) is a special kind of average that gives more weight to recent data and less weight to older data. It creates a smoothed trend line through your data. Anything that deviates sharply from that smooth line — a sudden spike or crash — gets flagged.

Think of it as the difference between the trend and the actual value. EWMA subtracts the smoothed trend from each actual reading. What's left (the residual) tells you what's unexpected. When the residual exceeds 3 standard deviations, EWMA fires.

SARIMA is a statistical forecasting model that understands seasonality — predictable patterns that repeat at regular intervals. It learns from your historical data: "Electricity usage is always high on Monday mornings. Revenue always dips on Sundays. Production throughput is always lower on night shifts." It builds a model of what your data should look like at any given time based on those patterns.

Once SARIMA has learned the seasonal model, it computes what it expected at each point, and compares that to what actually happened. The difference (the residual) is what gets analysed for anomalies. A Sunday revenue figure that looks low by absolute standards might be perfectly normal for a Sunday — SARIMA knows this and won't flag it.

Isolation Forest is an unsupervised machine learning algorithm that works by trying to isolate each data point from the rest of the dataset using random cuts. Normal points — those that cluster with similar points — require many cuts to isolate because there are lots of similar points nearby. Anomalous points — those that are unusual — can be isolated in very few cuts because they're far from everything else.

Crucially, Isolation Forest looks at all your columns simultaneously. A reading might be within normal range on any single metric, but if the combination of values is unusual across three or four metrics together, Isolation Forest finds it. This is the key method for catching multi-metric anomalies that single-column monitoring would never detect.

Some metrics in your data are naturally correlated — they tend to move up and down together. Revenue and units sold. Power consumption and production output. Delivery volume and fuel cost. Correlation Deviation monitors these relationships over time. When two metrics that have historically moved together suddenly diverge — or when two metrics that normally move independently start moving in lockstep — that's flagged as an anomaly.

This method is particularly powerful for catching process failures that don't show up in any single column. If your OEE stays flat but your reject rate climbs, something has changed in the relationship between those metrics — even if neither column individually looks alarming.

DBSCAN (Density-Based Spatial Clustering of Applications with Noise) groups your data into clusters based on density — regions where data points are close together. Points that belong to a dense cluster are normal. Points that sit far from any cluster, in low-density regions of the data space, are labelled "noise" — and those noise points are anomalies.

Unlike methods that flag values outside a threshold, DBSCAN doesn't need to know in advance what "normal" looks like. It discovers the natural clusters in your data and then identifies what doesn't fit. This makes it excellent at catching systematic patterns that are unusual — like a specific product SKU that consistently returns at a different rate from all similar products, or a meter that always reads in a pattern no other meter produces.

The Seasonal Baseline method builds a separate statistical profile for each time bucket in your data. For hourly data, it calculates a normal mean and standard deviation for each hour of the day and each day of the week independently — so "normal for 3am on a Sunday" and "normal for 3pm on a Tuesday" are tracked separately.

This is simpler than SARIMA (it doesn't build a full forecasting model) but it's very effective at eliminating false positives caused by predictable time-based patterns. Night-shift throughput, weekend call volumes, Monday morning order surges — all of these are learned as patterns specific to their time bucket and excluded from anomaly detection.

Trend Detection compares the mean value across consecutive rolling windows of 50 data points each. If the mean is consistently moving in one direction — each window's average is higher (or lower) than the previous window's average, across three or more consecutive windows — a trend is flagged. This is monotonic drift: not a spike, not a step change, but a steady, persistent movement in one direction.

This is the method that gives you weeks of advance warning on bearing wear, budget overruns that build slowly, and supplier performance that's eroding imperceptibly. No single period looks alarming. The direction across periods is the signal.

This is the most straightforward of the nine methods, but it catches some of the most expensive failures. It monitors for two specific patterns:

1. Stuck values: The same number appearing repeatedly across a rolling window. A live sensor that outputs 47.3 for 20 consecutive readings isn't measuring anything — it's frozen. This indicates sensor failure, PLC communication loss, or a data pipeline that's stuck replaying stale data.
2. Zero values: A metric that has been producing non-zero readings suddenly drops to exactly zero. This indicates a complete equipment stoppage, a service disconnection, a tracking pixel going offline, or a meter that has stopped registering.

Both patterns immediately escalate to Emergency severity — not Warning, not Critical. They indicate that your monitoring data is no longer trustworthy, which is worse than a bad reading. You can act on an anomalous reading. You can't act on data that secretly stopped updating.