Panic Button
The Panic Button turns a BLE beacon with a button into a portable emergency trigger. When the button is pressed, ION Guard raises a critical alert, locates the person by the zone where the signal was picked up, and opens a dedicated response console in the Command Center, with a deadline timer, a step-by-step protocol, the contacts to call and a complete trail of what was done.
What a press means is up to the customer: duress, assault, sudden illness, workplace accident, someone trapped in a room, or any other situation where a person needs help and cannot (or should not) pick up the phone.
Access path: Side menu > Command Center (the console opens by itself whenever there is an active panic)
The panic alert is produced by the panic-button sub-feature of the Synapsys module, which must be enabled for the site. The handling side (console, deadline, protocol, chain and trail) is part of the platform and does not depend on other modules.
How it works
1. The person presses the button on the beacon
↓
2. The antenna (Radium Gateway) picks up the signal and publishes it to the MQTT broker
↓
3. ION Guard creates a panic alert (Critical severity) in the antenna's zone
↓
4. The response console opens in the Command Center, with the alert sound
and the handling deadline timer running
↓
5. In parallel, the call chain notifies the site contacts
(e-mail and/or Telegram) at the configured times
↓
6. The operator acknowledges, follows the protocol, calls the people in charge
and closes the alert. Every action becomes a stamp on the trail
The trigger also works without internet at the site: the Radium Gateway has local panic rules that drive physical outputs (siren, light) and buffers the signal to resend it to the server, with the original timestamp, once the connection is back. See Radium commissioning.
What you need
| Component | Role | Reference |
|---|---|---|
| Beacon with button | Portable device the person carries (card, pendant or wristband). Registered in ION Guard with the Panic Button type | Beacons · Beacon catalog |
| Antenna | BLE gateway that picks up the signal and sends it to the server. Defines the zone in which the panic is located | Antennas · Radium |
| Zones and floor plan | Give the operator the "where": the zone shows on the alert and the floor plan is displayed in the console | Zones |
| Site contacts | Who the control room calls when a panic fires | Site contacts |
| Call chain | Who is notified, through which channel and how long after the trigger | Call chain |
| Response protocol | The steps the operator ticks while handling the panic | Response protocol |
The approved models with a button are in the beacon catalog: SOS card, emergency pendant and wristband. All of them use the same flow; the difference is the form factor and battery life.
The panic alert
| Attribute | Value |
|---|---|
| Type | Panic (panic) |
| Severity | Critical |
| Source | Beacon (Panic Button type) |
| Zone | Zone of the antenna that picked up the signal (or "Zone not determined") |
| Auto-resolution | Never. Requires manual action by an operator, even if the beacon returns to normal |
| Alert sound | Yes, on every screen, until acknowledged or muted |
| Escalation | Yes, 120 seconds without acknowledgement (see Escalation) |
| Handling deadline (SLA) | Yes, 180 seconds by default (see below) |
Once created, the alert shows in the top banner, the sidebar badge, the Alerts list and the Command Center map, which switches to the response console.
Response console
Panic is not a separate screen: it is a state of the Command Center. Whoever is watching the map when the button is pressed is already on the right screen, with no transition. The console shows, in a single view:
Command Center in panic state: "Panic at [site]" header with zone and time, circular deadline timer, Acknowledge and Close buttons, contacts column with the call chain, protocol with its steps, and the trail.
| Area | What it shows |
|---|---|
| Header | "Panic at site", the zone where it was triggered, the time and, after acknowledgement, who acknowledged it |
| Deadline timer | Circular gauge with the remaining handling time. Turns into "deadline breached" when it expires and "handled in time" once handled |
| Acknowledge / Close | The operator's two actions. Close stays blocked while there are required protocol steps left ("n required steps before closing") |
| Contacts · call chain | The site contacts, in chain order, with each step's state: "enters the chain in time", "step due now" or "notified at time". Every contact has a Call button |
| Protocol | The response checklist. Every tick becomes a stamp on the trail |
| Trail | The alert's timeline, from trigger to closure |
| Floor plan | The site's floor plan with the trigger zone highlighted (Show map / Back to response) |
Focus by URL
The console targets a specific case through the URL: /command-center?case={alert id}. This is the link that goes into e-mail and Telegram notifications, so whoever opens the message lands on the right panic, not the first one in the queue. It also works for wallboard shortcuts.
Calling a contact
The Call button opens the device dialer (tel:) and stamps Call started on the trail, with the contact and the time. Repeated calls ("Call again") are recorded too. ION Guard does not place the call nor verify whether it was answered; what is recorded is the attempt.
If the site has no contacts registered, the console shows "No contacts registered" with a shortcut to the registration screen. The operator meets the deadline up to acknowledgement and gets stuck on the step that actually matters.
Handling deadline (SLA)
Every panic alert is born with a handling deadline, 180 seconds from the trigger by default. The deadline is measured by the system, not by the operator:
- The timer is shown in the console and on the alert page.
- In the current version, the milestone that stops the timer is the acknowledgement of the alert.
- If the deadline expires without acknowledgement, the system stamps SLA deadline breached on the trail, with the exact expiry time, and fires the
alert.sla_breachedwebhook. The sweep runs every 30 seconds, but the recorded time is the deadline itself, so the accuracy of the record does not depend on the interval.
The deadline can be adjusted per site or per organization, between 30 seconds and 1 hour, and must be longer than the escalation time. It can also be turned off for customers with no contractual deadline. This adjustment is made by the IONGRADE technical team.
A silently inactive deadline is only discovered on the day someone asks how long the control room took. Starting at 180 seconds guarantees the trail records performance from the very first panic; those who do not need it turn it off.
Trail
The trail is the alert's timeline, stored in its own table and immutable through the interface. Every stamp has a time, an author (operator, System or Integration) and what happened:
| Stamp | When |
|---|---|
| Alert created | The button was pressed and the alert raised |
| Operator viewed | An operator opened the case in the console (only the focused case gets the stamp) |
| Acknowledged | The operator clicked Acknowledge |
| Escalated | A step of the call chain ran |
| Notification sent / Notification failed | Result of each e-mail or Telegram delivery |
| Protocol item completed / uncompleted | The operator ticked or unticked a step |
| Call started | The operator clicked Call |
| SLA deadline breached | The deadline expired without acknowledgement |
| Resolved | The operator closed the alert |
The trail is what later answers questions such as "how long until someone saw it?", "who was notified and when?" and "was the person in charge reached within the deadline?".
Site contacts
Access path: Side menu > Infrastructure > Contacts (with a site selected)
Contacts are the people the control room reaches when a panic fires: the person in charge of the unit, security, fire brigade, a police or ambulance liaison, and so on. The order of the list is the order of the call chain.
Site contacts screen with the ordered list (name, role, phones, channels, active) and the Move up the chain / Move down the chain controls.
| Field | Description |
|---|---|
| Name | Contact name |
| Role | Manager, Treasury, Security, Police liaison or Other |
| Primary / alternate phone | Used by the console's Call button |
| Destination for the e-mail channel | |
| Telegram (chat ID) | Destination for the Telegram channel |
| Active | An inactive contact leaves the chain without losing history |
| Order | Position in the chain (Move up the chain / Move down the chain) |
Contacts may come from an external source (integration); in that case they can only be activated or deactivated from ION Guard. Removing a contact takes it out of the chain but preserves the history of past alerts.
Users with the Viewer role see the phone number masked. Operators and higher roles see the full number.
Call chain
Access path: Side menu > Administration > Escalation
The chain defines who is notified, through which channel and how long after the trigger. The point is never to depend on a single person: if the operator on screen does not acknowledge, the net widens automatically.
Call chain screen with the chain name and its steps (After N seconds, Contact no., Channels), and the Add step button.
Every step has:
| Field | Description |
|---|---|
| After (seconds) | Time after the trigger when the step runs. Each step must wait longer than the previous one (0 to 3600 s) |
| Contact no. | Position of the contact in the site list. Left blank, it notifies all active contacts |
| Channels | E-mail and/or Telegram |
Operating rules:
- The chain is configured per organization (applies to all sites) and can have up to 10 steps. A site-specific chain, when one exists, overrides the default.
- Steps are scheduled the moment the alert is created and run at the exact second, not on the next sweep.
- A step only fires if the alert is still active. Once the alert is acknowledged, pending steps are cancelled and recorded as such.
- Contacts may have an availability window in the site's time zone; anyone outside the window is not notified on that step. Without a window, the contact is always available.
- Every delivery stamps Notification sent or Notification failed on the trail, and the step flags the alert as Escalated.
The message is short: "Panic button triggered at site, zone zone", with the direct link to the case in the console.
Notification channels
| Channel | How to enable |
|---|---|
| Configured at installation (SMTP server or Amazon SES). Always available | |
| Telegram | Off by default. Requires a Telegram bot and each contact's chat ID. Enabled by the technical team, since the site name and the fact that a panic occurred leave for third-party infrastructure, which may conflict with the customer's information security policy |
Response protocol
Access path: Side menu > Administration > Protocol
The protocol is the checklist the operator ticks while handling a panic. It belongs to the organization (not the site) and exists to give the trail granularity: without a protocol, the trail only goes from "acknowledged" to "resolved".
Response protocol screen with the numbered steps, the required switch and the Move up / Move down / Remove controls.
Every organization starts with a default four-step protocol:
| Step | Required |
|---|---|
| I acknowledged the alert | Yes |
| I contacted the person in charge | Yes |
| I confirmed the situation | No |
| I recorded the outcome | No |
- Required steps block the Close button until they are ticked.
- A removed step is deactivated, not deleted: past alerts remain readable.
- Adapt the steps to the customer's procedure: "called the fire brigade", "confirmed on camera", "called the ambulance" and so on.
Site operational mode
Besides the administrative status (active, inactive, under maintenance), a site can temporarily be outside normal operation. The mode is shown on the Command Center map and in a strip with the count of sites in that situation, so the whole control room knows a panic may come from that unit at any moment.
| Mode | Use | Default duration |
|---|---|---|
| PF inspection | Inspection or button test by a regulatory body | 4 h |
| Maintenance | Maintenance window on the site's hardware | 8 h |
| Heightened attention | Control room decision (event, threat, nearby incident) | 24 h |
Every mode has an expiry and is closed automatically: a mode without a deadline stays on forever, the flag loses meaning and the control room learns to ignore it. The mode can be opened and closed through the API, which lets an external monitoring center flag the site.
Readiness and self-test
The worst failure in the flow is a silent one: the button is pressed and nothing arrives. That is why ION Guard checks each site's readiness every hour, and on demand through the API, with these checks:
| Check | What it verifies |
|---|---|
| Call contacts | Is there an active contact with a phone, e-mail or Telegram? A single contact is "degraded" (single point of failure) |
| Call chain | Is there a chain with steps for the site? |
| Panic devices | Is there a panic button registered? Are they online? Are the antennas online? |
The result (ok, degraded or down) is available on the readiness endpoint and in the site's self-test history.
API and integrations
To integrate panic with a monitoring center, a VMS or a ticketing system, ION Guard offers:
| Resource | Endpoint / event |
|---|---|
| List and fetch alerts | GET /api/v1/alerts, GET /api/v1/alerts/{id} |
| Acknowledge and resolve | POST /api/v1/alerts/{id}/acknowledge, POST /api/v1/alerts/{id}/resolve |
| Site operational mode | GET/POST/DELETE /api/v1/sites/{id}/operational-mode (site:mode scope) |
| Readiness | GET /api/v1/sites/{id}/readiness (readiness:read scope) |
| On-demand self-test | POST /api/v1/sites/{id}/self-test |
| Outbound webhooks (signed) | alert.created, alert.acknowledged, alert.resolved, alert.escalated, alert.sla_breached, site.mode_changed |
API tokens have scopes (abilities) and can be restricted by IP allowlist. Alerts accept an external reference (external_ref) for correlation with the ticket in the customer's system. Webhook endpoints are registered by the IONGRADE technical team.
On the physical reaction side, the DigiEye module can drive commands on equipment (siren, light, lock) when a panic alert is created, acknowledged, resolved or escalated.
See also the API documentation.
Audit report
The Panic Response Audit report produces one row per panic alert with every stamp, the derived durations (trigger to view, to acknowledgement, to contact), the deadline outcome and the full trail. The summary block carries the compliance aggregate and a content hash, so the delivered file can be checked against the stored record. Available to the Tenant Admin role and above, with a filter to include only triggers made in inspection mode.
Use cases
- Duress and assault: reception, guardhouse, customer service, treasury. The employee triggers without the aggressor noticing and the control room sees where they are.
- Accident and sudden illness: lone operator in an industrial area, warehouse or night shift. Button on the badge or wristband.
- Work in confined or cold environments: a person trapped or unwell inside a chamber, located as "inside chamber X". See Cold Room.
- Inspection and periodic testing: put the site in inspection mode, press the button and use the trail and the report as evidence of response time.
Next steps
- Alert Response: acknowledging and resolving
- Alert Escalation
- Command Center
- Beacons and Antennas
- Radium Gateway