Statistical anomaly detection

Catch readings that are unusual for this sensor without picking a fixed number. The platform learns each sensor's normal range from its recent history and alerts when a value strays too far.

Fixed threshold vs. learned normal

A plain AlertRule fires when a value crosses a number you choose — "alarm over 8000 W". Simple, but you have to know the right number, and one number rarely fits every machine, shift, or season.

A statistical rule chooses the boundary for you. It watches the sensor's own recent readings, works out what "normal" looks like, and fires when a reading is unusual compared to that history. Nothing to guess up front — useful for catching subtle drift you never had a fixed limit for.

How it decides: mean ± Nσ

Two numbers describe "normal", both measured live from a rolling window of recent readings:

• mean — the recent average.
• σ (sigma) — the standard deviation: the typical amount the reading wobbles around that average.

A reading's distance from normal is measured in σ (a z-score): (value − mean) / σ. The rule fires when that distance exceeds N — the sensitivity you set.

Worked example — a motor's temperature. Over the recent window the platform measures mean ≈ 65 °C and σ ≈ 8.5 °C. With N = 3, the normal band is:

65 °C ± (3 × 8.5 °C)  →  39.5 °C … 90.5 °C is "normal"

A reading of 100 °C sits (100 − 65) / 8.5 = 4.1σ above the mean — past the 3σ line, so it fires.

Why 3 is a sensible default. For data that follows a typical bell curve, about 99.7 % of readings fall within ±3σ. So 3σ flags only the rarest ~0.3 % — unusual enough to be worth a look, without crying wolf. Turn N down to catch subtler deviations (more alerts), or up to catch only dramatic ones.

Configure a rule

A statistical rule replaces the operator/threshold fields with these:

Statistical rules apply to numeric sensors. The operator and threshold fields used by fixed-threshold rules don't apply and are hidden.

Set it up

In the app. Open a device, expand the sensor, choose Create Rule, and set Strategy → Statistical anomaly. Fill in the fields above and save.

In the API. POST /api/v1/alert-rules with evaluationStrategy: "ROLLING_STATISTICAL":

{
  "name": "Motor temperature anomaly (3σ)",
  "sensorId": "<sensor id>",
  "evaluationStrategy": "ROLLING_STATISTICAL",
  "detectionMethod": "ZSCORE",
  "windowDurationMs": 3600000,
  "stdDevs": 3.0,
  "minSamples": 30,
  "anomalyDirection": "BOTH",
  "minConsecutiveBreaches": 3,
  "severity": "WARNING",
  "cooldownDurationMs": 300000,
  "channelIds": ["<email channel id>"]
}

detectionMethod is required for statistical rules — ZSCORE is the method available today. anomalyDirection is one of ABOVE, BELOW, BOTH. windowDurationMs and cooldownDurationMs are milliseconds.

What fires, and what you see

When the rule trips, it fires through the same pipeline as any alert — an Event with an EventLifecycle you acknowledge and resolve, plus notifications and (if configured) media capture.

The alert detail shows the context behind the fire, for example:

100 °C — 4.1σ above the rolling mean (65 ± 8.5)

so you can see how unusual the reading was, not just that it crossed a line.

Good to know

• It detects onsets. A statistical rule is best at flagging when something starts behaving abnormally. If a problem persists for a long time, the rolling baseline gradually treats the new level as normal and the rule goes quiet. For hard limits that must always alert, pair it with a fixed-threshold rule.
• Tune N in the first week. The 99.7 % figure assumes a clean bell curve; real signals aren't perfect. Start at 3 and adjust against the false-positive rate you actually observe.
• No seasonality model. A flat rolling window doesn't know about daily or shift cycles. For a signal with strong recurring patterns, use a shorter baseline window or a higher N so routine transitions don't read as anomalies.
• Numeric sensors only. Boolean and text channels use fixed-threshold rules instead.