Before you rely on a notification reaching someone

The honest framing

A notification is a request to a phone to make a noise, delivered over a network, through an operating system that has its own opinions about batteries and interruptions. Every layer in that chain is allowed to delay it, and several are allowed to drop it silently.

Nothing here is a defect in a particular app. It is the shape of the medium, and the useful response is to test it on the actual phones involved and then decide what you are willing to depend on.

Nine reasons a phone stays silent

1. The phone is on silent. Far and away the most common, and the most embarrassing to discover afterwards. Test by sending one while the phone sits where it normally sits.
2. Do Not Disturb, or a Focus mode, or a sleep schedule. These often turn themselves on by timetable, so a setup that works all afternoon fails every night. Most systems allow specific apps or people through — set that up deliberately rather than assuming.
3. Battery optimisation, on Android especially. Manufacturers add aggressive power management on top of Android, and it can stop an app being woken for hours. If a phone gets messages instantly when in use and hours late otherwise, this is almost always why. Look for a per-app battery setting and set it to unrestricted.
4. Notification permission was never granted, or was revoked. Modern phones ask once, at a moment when the person is trying to get past the dialog. Check the setting rather than trusting a memory of tapping something.
5. The app was force-closed. Swiping an app away from the recents list stops some phones delivering its notifications at all until it is reopened.
6. No signal, or hotel and hospital Wi-Fi. Captive portals are the ugly case: the phone believes it is connected and nothing arrives. Messages generally turn up when connectivity returns, which can be much later.
7. The phone is off, or flat. Obvious, and worth including because it is indistinguishable at the sending end from every other case on this list.
8. It arrived and nobody noticed. A phone in a coat in the hall did its job perfectly. This is not a technical failure and it is one of the most common real ones.
9. It arrived, was glanced at, and was forgotten. Notifications are cleared reflexively. If the only record of a request is a banner that has been swiped away, the request is gone.

How to actually test it

Ten minutes of testing beats any amount of reading, and almost nobody does it because sending one message in the setup meeting feels like enough. It is not — the setup meeting is the best case in every respect.

1. Send one while the phone is locked and in a pocket, not in a hand.
2. Send one at night, with whatever sleep or focus schedule normally runs.
3. Send one after the phone has been untouched for a few hours. This is the test that catches battery optimisation, and it is the one people skip.
4. Send one from the far end of the house, on the Wi-Fi that is actually there.
5. Repeat every test on each phone. Two handsets from the same maker can behave differently.
6. Re-test after a phone update or a new phone, because power settings reset.

Write down what happened. “I think it worked” a fortnight ago is not evidence, and this is exactly the sort of thing everyone misremembers optimistically.

Design the arrangement so a miss is survivable

Since you cannot make delivery certain, the useful work is making a missed message not matter very much.

• More than one recipient. The single biggest improvement available, because the failures above are mostly independent — one phone on silent is likely, three phones silent at once is not.
• A reply that closes the loop. The person who asked should be told somebody is coming. Silence is the ambiguous state, and it is the one that makes people give up asking.
• Something that persists. A banner that has been swiped away leaves no trace. A request that stays visible until somebody deals with it survives being glanced at.
• An agreed fallback. Say out loud what happens if nothing comes back within a few minutes — phone instead, or knock on the door. An unstated fallback is not one.
• Do not use it for anything that cannot wait. This is the whole rule underneath the others. If the consequence of a fifteen-minute delay is serious, a phone notification is the wrong mechanism, and no amount of configuration makes it the right one.

What to ask anybody selling you one of these

A short list of questions with uncomfortable answers, which is why they are worth asking:

• Does it escalate if nobody answers? Most do not. Ours does not.
• Can the sender see whether it was delivered, or only that it was sent? Those are very different, and the second is often presented as the first.
• What happens when the internet is down? Anything running over your broadband stops. Wired systems generally do not.
• Is anybody monitoring it? If the answer is no, it is not an alarm, whatever the marketing says.

If a product answers all four comfortably, it is probably a monitored alarm system with a contract and a price to match — and for some situations that is exactly what you should buy.

What this page will not tell you

We build software for sending a short message to somebody who agreed to receive it. That is the entire extent of what we know, and these pages stay inside it.

• What to do in an emergency. Nothing on this page makes a phone suitable for one, and no arrangement of settings changes that.
• Whether somebody should be relying on a phone at all. Sometimes the answer is a monitored alarm, a person, or a device with its own power and its own line.
• Specific handset behaviour on every make and model. Manufacturers change power management between versions, and the only reliable check is testing the actual phone.
• Anything about the person’s health or the level of support they need.