A threshold compresses a continuous number into a normal-or-abnormal judgment readers can act on fast
Aliases: thresholding · binary state
What it is
A threshold is a cognitive compressor: it squeezes the continuous judgement "is the error rate 0.3% or 0.31%" into the binary state "normal / abnormal," letting readers finish the "do I need to act" decision without reading numbers. This compression is what makes monitoring scalable — hundreds of metrics each flashing a light is the only thing human attention can sweep. Compression always loses information, and threshold design is deciding what to lose and what to keep.
Why it happens
The threshold can carry the compression because it front-loads the business judgement: setting a threshold is answering "how bad counts as abnormal," and the red-green state on screen is that definition unfolding at runtime. The information loss concentrates in two places: discrimination near the boundary — 0.29 and 0.31 sit on opposite sides as if categorically different, though they differ by a hair; and magnitude — "just crossed" and "badly over" are flattened onto the same side. That is exactly why raw values usually stay beside the threshold state: the binary state handles fast triage, the number handles degree, and the two cooperate rather than substitute. A threshold also changes the metric's behavioural meaning — once an instrument carries a threshold and alerts, its fluctuations stop being data phenomena and become operational events, an upgrade in semantics that demands business confirmation of the threshold rather than a technical default.
Where it stops holding
Thresholding suits metrics with binary judgement and graded action (availability, SLA, stock floors), not all metrics — thresholding an exploratory metric (usage distribution of a new feature) closes the observation window prematurely. Thresholds also go stale: after business changes, old thresholds misfire while the instrument still shows "green," and false negatives are harder to spot than false positives, so thresholds need periodic review (next card). A hysteresis band is the standard patch: a buffer around the threshold prevents the state from flapping when the metric hovers at the line.
Applying it
- Confirm every monitored metric has a business-endorsed threshold; metrics without one, and unfit for one, go to the observation class and stay out of the traffic lights.
- Keep the raw value beside the threshold state — binary triage and degree judgement coexist.
- Add a buffer band near the threshold to damp critical flapping.
- Verification: replay five minutes of monitoring data and check that every state flip corresponds to a business-endorsed anomaly; false positives clustered at the boundary call for the buffer band.
Related
- Same group: U7.04.2 The threshold's rationale must be visible and adjustable · U7.04.3 Single-point breaches and sustained breaches deserve different responses · U7.04.4 Too many alerts train users to ignore alerts · U7.04.5 Alerts must point to the executable next step, not just report the value
- Nearby: U7.02.1 Monitoring dashboards optimise for anomaly detection · U7.05.1 A single value means something only against a baseline
- Search terms:
threshold alerting·state compression·SLO threshold
Cards in the same group
- U7.04.2A threshold is a human decision, not a law of nature, so its rationale should be visible and adjustable
- U7.04.3Crossing a threshold once and crossing it continuously are different problems needing different responses
- U7.04.4A flood of unimportant alerts teaches users the rational response is to stop paying attention
- U7.04.5An alert that reports a number without saying what to do next has only done half its job