Work through these in order. The list is ordered by how often each is actually the cause, and the first two account for the large majority of cases.
MassComs supports your organisation’s safety plan. It does not replace authorised instructions, trained judgement or emergency services.
Before you start
Have these ready.
- The device in your hand — most of this cannot be diagnosed remotely.
- 01
Check critical alert permission
This is the first thing to check every time. Notification permission alone will not break through a silenced phone; critical alert permission will.
See Enable critical alerts and notifications.
- 02
Check the OS notification settings
Go to the operating system's settings for the app rather than trusting the app's own view. Confirm notifications are allowed, sounds are enabled, and the incident channel is not muted.
- iOS: Settings → Notifications → MassComs.
- Android: Settings → Apps → MassComs → Notifications, and check the incident channel specifically.
- 03
Check background and battery restrictions
Android battery optimisation and aggressive power-saving modes delay or drop background delivery. Exempt the app.
- 04
Check the account is in scope
An incident scoped to a zone reaches people resolved into that zone. If the person's site scope, role or location puts them outside it, the phone worked perfectly and the targeting excluded them.
This is worth checking early when one person missed an alert that colleagues in the same room received — that pattern is almost never a device problem.
- 05
Check the app is signed in
A session that has expired or been signed out receives nothing. Open the app and confirm the home screen shows System Ready with the right organisation.
- 06
Check connectivity at the time
A phone with no data at the moment of activation will receive when it reconnects, not when it mattered. Poor coverage inside a building is a real and common cause.
If a specific part of a building consistently misses alerts, that is a coverage problem to solve with fixed devices — Agents or signage — rather than with phones.
- 07
Verify the fix properly
Re-test with the phone locked and silenced, using a TEST-type incident. Do not close the ticket on the basis that the app opens.
Confirm it workedA locked, silenced phone makes a sound and shows the alert.
Troubleshooting
When it does not go to plan.
| Symptom | Usual cause | Fix |
|---|---|---|
| One person missed it, colleagues in the same room did not. | That device's permissions, or that account's scope. | Check permissions first, then the account's site scope and role. |
| Everyone in one area missed it. | Targeting or coverage, not devices. | Check that the area's rooms are assigned to the zone that was targeted. |
| Alerts arrive but silently, on every device. | The scenario's channels, or an organisation-level setting. | Check the scenario's channel configuration before auditing devices. |
| It worked last month and stopped. | An OS upgrade reset the permission. | Re-grant critical alerts. Build a post-upgrade re-check into your process. |
Good to know
Small details that prevent big confusion.
- One device silent is a device problem. A whole area silent is a targeting or coverage problem. Diagnose the pattern before the device.
- Nobody can grant critical alert permission centrally. It is per device, per person, every time.
- Fixed devices cover the places phones do not. If an area fails repeatedly, put an Agent or a screen in it.
Was this guide clear?