From number to action - when a system may raise the alarm on its own

A number nobody reads changes nothing.

Alerting is where measurement turns into action: throttle admission, open a second till, trigger cleaning, call security, switch an external system. It is also where a wrong number turns into a wrong action - with no person taking a second look in between.

So the question about alerts is not how many types a system knows, but: when may a system raise the alarm on its own? This article gives three answers. It builds on Measuring occupancy, which covers the number most alerts are calculated on, and on When a deviation is really a signal, which covers the statistics behind the anomaly alert.

Three conditions before a system may alert

An alert that comes too often gets ignored. One that comes for the wrong reason gets switched off. One that costs money nobody budgeted for gets cancelled. Each of these experiences turns alerting into an inbox nobody opens. Three conditions guard against them:

1. The system knows what it is looking at. No alert on data that is missing or stale. Silence is not a zero.
2. The system reports once. A state that lasts an hour produces one message, not sixty.
3. The system costs no more than agreed. A budget checked before sending, not afterwards.

Everything else in this article is how those three sentences are put into practice.

Eight triggers that are actually evaluated

The number of alert types matters less than what each one triggers on and how often it is checked:

The two-way threshold and its use at a station are covered in Passenger counting in public transport, the capacity reconciliation in Measuring occupancy. This is about what all eight have to share.

When a dead sensor reports minus 100 per cent

The trend alert is the most useful and the most dangerous at once. Useful, because a 20-per-cent drop otherwise shows up in the monthly report, three weeks late. Dangerous, because the most common reason for a slump in the data is not a market event but a sensor that has stopped sending.

It is easy to play through: if a sensor fails and the trend alert checks nothing else, it reports “−100 per cent” every day - after eight days, that is eight paid messages. Each is arithmetically correct. None is true.

That is why a trend alert may only fire if the comparison actually holds:

• Both comparison windows need at least five out of seven days with actual data.
• The baseline window needs at least 50 visitors, otherwise any percentage is a random number.
• Repeats are damped: if the deviation has barely moved, there is no second message within seven days.

The comparison is against the previous week, the previous month or the same week a year earlier - weekday-aligned, offset by 364 days rather than 365. Otherwise a Monday would stand against a Sunday, and the alert would report the weekday every week instead of a change.

The message arrives early every morning, with a recipient list per site. Operations and management do not have to receive the same one.

Never on the unknown

The first condition - the system knows what it is looking at - applies to every alert, not just the trend.

For the zone alert it means: zones without current data are filtered out before the check. The system does not alert on a zone it cannot currently see. The same rule applies to handing data to building services, described in Occupied versus paid-for space.

And because an outage still needs reporting, it has an alert of its own: sensor offline and back. It is checked every 15 minutes, and only within opening hours - a sensor that sends nothing at night in a closed store is not an outage. The return message follows with the first new transmission.

That way an outage lands in the inbox as an outage, not as a drop in footfall. That is the whole difference between a technician checking the cable and a store manager justifying themselves.

Restricted areas: one person is one too many

For a store room, plant room, staff door or track area, no threshold helps. Access there is not a matter of numbers, and it is usually noticed only afterwards - when reviewing footage, once something is missing or something has happened.

So the restricted area is defined where counting happens: on the sensor. Name a zone or counting line there with a fixed restricted marker and every entry produces an immediate message - no threshold, no delay, with site, time and the areas affected. Several hits in the same transmission are merged into one message.

No badge, no lock, no retrofit on the door. And an area that moves gets renamed rather than rebuilt.

Report once, pay once

The second condition sounds obvious and technically is not. A state lasting an hour meets a sensor that transmits every few seconds. Without protection, every transmission produces a message.

The protection is a lock-out period, and it differs by trigger because triggers differ in urgency: one minute for a restricted area, 15 minutes for occupancy, 60 minutes for the usage counter. For zones the lock-out is held as an atomic claim in the database - two servers seeing the same threshold at the same moment do not report twice.

The anomaly alert goes one step further. A notification register per tenant, site, calendar day and metric records what has already been reported. The same anomaly reports exactly once and costs exactly once. That too is a single atomic write, not a read followed by a write with room for a second run in between.

The anomaly alert's sensitivity can be set in three levels - from “only the obvious” to “the quiet ones too” - and it measures each site against its own last 30 days. A station and a boutique therefore need no separate rules.

Five channels and a budget that cannot be overdrawn

An alert has to arrive where the shift is actually looking. That is rarely the store manager's inbox.

The third condition - the system costs no more than agreed - depends on the order. The budget is reserved before sending, in a single conditional write: usage is only increased if usage plus the cost of this send does not exceed the monthly budget. If it does not fit, the send is refused beforehand - not halfway through the recipient list, with half-delivered alerts.

The difference from the usual order - send first, bill afterwards - shows on the day two alerts arrive at once. If both check first and then write, both see the same remaining budget and both go out. If check and charge are one step, only as much goes out as the budget covers.

Every send then appears in the history: trigger, trigger value, threshold, time, per recipient the channel and delivery status, and the credits actually used. The history is kept for 395 days - long enough for a year-on-year comparison and as evidence in dealings with cleaning and security contractors. And every alert email carries a personal unsubscribe link, so a recipient can opt out without the channel being blocked for everyone.

When an external system should switch

Traffic light, display board, door control, ticketing system: they react as fast as the person watching the dashboard. For admission control that is too slow. And giving every external system access to the analytics system is not a solution but a security problem.

The solution is the reverse route: a rule calls the external system. It consists of several conditions that must all hold - occupancy above one value and visitor count below another, say -, a connection to the target, a lock-out between one minute and 24 hours, and optionally an active window. If everything holds, the system calls the endpoint with the authentication and message format the target expects. Up to 25 connections per site are possible, each with its own credentials.

An automatic call into a foreign network is a security decision, and the path is built accordingly:

• The target address is checked again immediately before every call, including name resolution. Internal addresses are excluded, redirects are refused rather than followed.
• One trigger, one call. The lock-out is claimed atomically before sending.
• Retries with growing gaps: up to six attempts within 30 seconds.
• A dead target is not called forever. After five failures in a row the connection is switched off and an error alert is raised.
• Credentials are stored encrypted and appear in no log.

One detail shows how differently two similar things must be treated. The call to an external system is retried up to six times, alert delivery to people only up to three. An alert delivered late has no value left - the queue is already there. A traffic light, on the other hand, should still get its state even if the network coughs briefly.

Every rule can be checked beforehand in a test run, and an execution log shows what was sent and what came back.

What belongs in the tender

1. Can an alert fire on missing or stale data - and how is a sensor outage reported?
2. How often does a state lasting an hour report? Are there lock-out periods per trigger?
3. Is the budget checked before sending or billed afterwards?
4. Which channels deliver, and is delivery status per recipient kept in a history?
5. How does the system call an external system - and what stops it calling into the internal network?
6. What happens if the target does not answer?

How we do it

The ANALYSIT Counting System evaluates eight alert triggers: occupancy in both directions with an optional time window, restricted areas, zone capacity, the cumulative usage counter, the daily trend against previous week, month or same week last year, the anomaly alert against the site's own last 30 days, sensor offline and back, and capacity reconciliation discrepancies.

The trend alert only fires with at least five days of data per window and 50 visitors in the baseline; zones without current data are filtered out before every check. Lock-out periods per trigger and a notification register for the anomaly alert ensure the same state reports once.

Delivery runs via email, SMS, WhatsApp, Slack and Microsoft Teams, with a monthly budget reserved atomically before sending and a history with delivery status per recipient over 395 days. External systems are called via rules with several conditions, with target-address checks, retries, automatic switch-off, test run and execution log.

If someone in your organisation currently watches a number so that something happens, talk to us. The first question is then usually not the threshold but what should happen when the sensor goes quiet.