Engineering · Alerts

Threshold alerts that do not cry wolf

The first alerting system every ops team turns off is the one that pings every dwell spike. Useful alerts have hysteresis, calm-periods and a routing graph. Here is how the Occivar alerts layer is built, and where the defaults come from.

A dark control-room screen showing a chart with red threshold markers
A threshold, a sustained duration, an ack-required push to the right device

The first alerting system every operations team turns off is the one that pings on every dwell spike. The reason isn't usually the threshold: it's the absence of hysteresis, the absence of a calm-period, and the absence of a routing graph that ends at a specific person.

The Occivar alerts layer is built around three rules that decide whether a threshold crossing is worth a notification at all.

01 · RULE ONE: HYSTERESIS, NOT INSTANTANEOUS TRIGGERSRule one: hysteresis, not instantaneous triggers

A zone that touches a threshold for half a second and recedes is not an alert. A zone that sustains it for a defined window is. Every threshold on the platform has a sustain duration alongside it: a density level only fires once it has held for N seconds. The defaults are tuned to the use case: eight seconds for crowd-safety, four minutes for HVAC right-sizing, fifteen minutes for utilisation review.

Hysteresis kills the most common false-positive class (a transient cluster crossing the threshold for a single tick) without losing the durable ones.

02 · RULE TWO: CALM-PERIOD AFTER RECOVERYRule two: calm-period after recovery

Once an alert fires, the same rule cannot re-fire for a configurable calm-period. The platform watches the recovery curve and only re-arms the rule when density has been below the recovery threshold for M seconds. This is the difference between a single alert "Gate B sustained 92%, four minutes" and a stream of fifteen near-identical pings as the density oscillates around the threshold.

The recovery threshold is set lower than the firing threshold by default (a ten-point margin), so the platform isn't asked to count a steady-state-near-threshold as recovered.

03 · RULE THREE: ROUTING GRAPH, NOT A BROADCASTRule three: routing graph, not a broadcast

A useful alert has a single recipient by default. The routing graph maps zone + alert-class + shift + on-call rota to a specific device. An attendant on the affected floor is paged with a one-tap acknowledgement; a supervisor is paged on escalation; an operations channel is informed for awareness. There is no broadcast-to-all path on the platform, because broadcast alerts get muted.

Escalation paths are configurable and auditable. Every ack is timestamped against the alert; every miss escalates after a configurable timeout.

04 · WHAT THE ALERT PAYLOAD ACTUALLY CONTAINSWhat the alert payload actually contains

A platform alert is small on purpose:

  • Zone identifier and label.
  • Threshold class and current value.
  • Sustain duration so far.
  • A link to the relevant zone in the dashboard.
  • The ack action.

What is not in the payload: anything identifying. No frames, no faces, no demographic inference, no attendee information. The alert is a density signal, not a surveillance signal. The architecture means it can't be anything else.

05 · HOW ALERTS FIT THE REST OF THE PLATFORMHow alerts fit the rest of the platform

Threshold alerts sit between the live occupancy analytics and the operational response. They consume the per-zone counts that occupancy analytics emits, and they route into integrations: Slack, Teams, SMS or a runbook on the building management system. The reports layer logs every alert and ack into the post-event reconciliation.

If the last alerting system on the floor cried wolf and got muted, the conversation worth having is about the rules, not the threshold.

If your building can't answer one of these questions yet, we should talk.