Sentry

What an emergency button should refuse to do

When a guard presses panic on a shared handset, Sentry does not put a name on the alert. It says Unidentified employee. That is deliberate, and it is the decision people question most.

What an emergency button should refuse to do

When a guard presses the panic button on a shared site handset, Sentry's panic button app does not put a name on the alert. It names the device and the site, and says "Unidentified employee".

That is a deliberate decision and it is the one people question most, so it is worth explaining.

Why a panic button app should not guess a name

A site handset is shared. It sits at the post, not in a pocket, and the guard holding it at 02:00 is not necessarily the one who used it at 18:00. There is usually nobody logged in, because logging in before you can call for help is a design that gets people hurt.

So when the button goes, we know the device and we know the site. We do not know who is holding it.

We could put the last known name on the alert. It would look better in a demo and it would be right most of the time. But "most of the time" is doing a lot of work in a sentence about an emergency. A name that is wrong goes into the notification, into the WhatsApp message, into the record, and eventually into whatever inquiry follows. Somebody is dispatched looking for the wrong person, and a document now says a guard was in an incident they were not in.

The cost of being wrong is high and it lands entirely on the guard. So the alert carries what we actually know.

What it does carry

The site. The device. A location fix. And the time the button was pressed, which is not always the time you receive it.

That last one matters more than it sounds. If the handset had no signal, the alert queues and sends when coverage returns, carrying the original press time. The control room sees both times and a line saying it arrived late.

Without that, a two hour old emergency looks like a fresh one. Somebody responds to the wrong situation, urgently, at the wrong place. With it, the operator knows immediately that they are looking at something that has already been happening for two hours, which is a completely different response.

What we do show, carefully

There is context we can offer without pretending it is identity. If a guard verified themselves on that handset twenty minutes earlier, that is worth knowing, and it appears clearly labelled as the last verification on that device rather than as the subject of the alert.

The distinction is not pedantry. "J. Dlamini, verified on this handset 21 minutes ago" is useful. "J. Dlamini has pressed panic" is a claim we cannot support.

The measured part

From press to control room, on a real handset over a mobile network, the alert reaches the backend in about 30 milliseconds over eight network hops. That was measured on a live device in September 2026, not modelled.

The number is less interesting than what it rules out. The delay in a panic pipeline is almost never the network. It is queueing behind a notification service, or waiting for a dispatcher to see something, or an alert that went to one person who was away from the desk. Which is why the alert goes to a notification, a webhook and a WhatsApp message at the same time rather than in sequence.


The panic pipeline in more detail, including what happens when nobody acknowledges, is the subject of a later post.