Predictive Alerting vs Threshold Alerting: A Field Comparison

Threshold alerting has a single virtue: it's simple to explain. Set a value, get an alert when the sensor exceeds that value. Operations teams understand it intuitively, and there's no argument about what triggered an alert. The number was above the line. The alert fired.

The problem is that "simple" is doing a lot of work there, and the costs of threshold alerting at scale are not simple at all.

How Threshold Alerting Fails in Practice

A typical bearing temperature sensor on a motor might have a threshold set at 90°C. During a summer heat wave, ambient temperature in the machine room runs 15°C higher than normal, and the motor's steady-state operating temperature climbs to 88°C — still within specification, but firing a nuisance alert every afternoon because it's briefly within 2 degrees of the threshold.

The operations team, flooded with alerts that aren't actionable, does what every operations team eventually does: they raise the threshold to 95°C. Then to 100°C. Three months later, a motor with a developing fault reaches 98°C on a cool morning and the alert doesn't fire because the threshold is now 100°C. The motor fails at 2 AM on a Saturday.

This pattern — threshold creep driven by nuisance alert fatigue — is one of the most common failure modes we see in industrial monitoring programs. The technology worked. The alert engineering didn't.

The second failure mode is that fixed thresholds don't account for operating context. A pump running at 100% load should have different temperature expectations than the same pump running at 40% load. A compressor on a cold startup has different vibration characteristics than the same compressor at steady state. Threshold alerting treats all of these conditions identically, which means either the threshold is set conservatively enough to catch faults under worst-case conditions (generating nuisance alerts under normal conditions) or it's set for normal conditions (missing faults during high-load periods).

What Predictive Alerting Actually Means

The term "predictive alerting" covers a range of sophistication from basic statistical baselines to full machine learning models. The key distinction from threshold alerting is that predictive alerting evaluates current sensor readings against an expected value given the current context, not against a fixed absolute value.

The simplest form is dynamic baseline alerting: for each sensor, maintain a rolling baseline of expected values segmented by operating conditions (load, time of day, ambient temperature). Alert when current reading deviates from baseline by more than a configurable number of standard deviations. This approach requires no ML infrastructure, updates automatically as operating conditions change, and dramatically reduces nuisance alert rates while improving sensitivity to real anomalies.

We ran this comparison directly on a deployment at a food processing facility: 47 motors, each with one temperature sensor and one current sensor. Under fixed threshold alerting (configured by the facility's maintenance team), the system generated an average of 34 alerts per week. Approximately 22 of those were investigated and found to be nuisance alerts. 8 were real maintenance items, and 4 were true alarm conditions requiring immediate action.

After switching to dynamic baseline alerting with a 3-sigma threshold and operating context segments (load band + ambient temperature band), total alerts dropped to 11 per week. Of those, 1-2 were nuisance, 7-8 were maintenance items, and 1-2 were immediate alarms. Same sensor data. Same motors. Total alert volume dropped by 68%, actionable percentage increased from 35% to 82%.

The Lead Time Problem

Threshold alerting fires when the fault is already present and severe enough to push a reading past the threshold. This gives the operations team, at best, the time between "threshold exceeded" and "failure" to respond. For a catastrophic bearing fault, that window might be hours. For an electrical insulation failure on a high-voltage motor, it might be minutes.

Predictive alerting, in its more sophisticated forms, detects the statistical signature of a developing fault before any individual reading crosses a threshold. Bearing degradation shows up in vibration frequency spectrum changes — increased amplitude at the ball pass frequency outer race (BPFO) or ball pass frequency inner race (BPFI) — days to weeks before the vibration level itself becomes alarming.

In the vibration monitoring deployments we've run, predictive fault detection based on frequency domain trending provides an average of 18 days advance notice of bearing failure, compared to an average of 6 hours advance notice from simple vibration amplitude thresholds. That's the difference between a planned replacement during a maintenance window and an emergency repair during production.

When Threshold Alerting Still Makes Sense

Predictive alerting requires sufficient historical data to build a baseline — typically 2-4 weeks of normal operation before the model is useful. For a sensor that's monitoring a safety-critical parameter on newly commissioned equipment, you don't have historical data and can't wait for it. Threshold alerting is the right starting point, with a plan to transition to baseline alerting once operating history is established.

Threshold alerting is also appropriate for hard limits that have no context-dependent variation: a pressure relief valve setpoint, a maximum safe temperature for a chemical reactor, a minimum flow rate below which a pump will cavitate. These are engineering limits, not statistical norms. They should fire at the hard limit regardless of what the baseline model says.

The practical architecture most mature facilities land on: hard threshold alerts for absolute safety and equipment protection limits, combined with dynamic baseline alerts for early fault detection and maintenance prioritization. The two approaches are complementary, not competing.

The Alert Routing Problem

One thing both approaches share is the problem of alert routing: who gets notified, through what channel, and with what priority. We've seen facilities with excellent alert engineering that still had poor outcomes because a critical alert went to a pager that nobody carries on weekends. Alert model quality and alert delivery infrastructure are both necessary; neither alone is sufficient.