Guides

How to build a panic button that still works with bad signal

LISABEM is a Kenyan security company, and we built the app their guards and managers use: shift sign-in at the site, live location while on duty, incident reports, and a one-tap panic button. Most of the app could tolerate the occasional failure. The panic button could not.

Guards work nights at sites where the mobile signal is weak or drops out entirely. A panic button that works in the office and fails at 2 a.m. on a remote site is worse than having none, because the guard believes help is coming. This guide explains how we designed the alert to get through anyway, and the principles apply to any app where one message absolutely has to arrive.

Start from the failure, not the happy path

The obvious design is simple: tap the button, send a request to the server, the server notifies the managers. On a good connection that works every time. The question that shapes the real design is what happens when it doesn’t: the request times out, the phone is between towers, the data connection is up but nothing gets through.

So we listed the ways it could fail and made sure each one had an answer: no data connection, a slow connection that takes too long, the app being closed or the phone restarted before the alert is sent, and the alert arriving while every manager is asleep.

1. Save the alert on the phone first

The moment the guard taps the button, the alert is written to a queue on the phone before anything is sent. That means the alert exists even if the network is down, and it survives the app being closed. From then on, the phone keeps retrying the write until the server accepts it. Firebase’s offline persistence handles much of this, but the important decision is architectural: the alert is recorded locally first and delivered later, not sent once and hoped for.

2. Don’t wait forever for the server

Retrying in the background guarantees the alert arrives eventually, but eventually isn’t good enough in an emergency. So the phone also starts a timer. If the server hasn’t confirmed the alert within eight seconds, the phone stops waiting and texts the managers directly by SMS. SMS often gets through when mobile data won’t, because it needs far less from the network.

The background retry keeps running after the text is sent. Whichever channel succeeds first, the alert ends up recorded on the server too, with the guard’s location and time, so the incident appears in the dashboard and the reports.

3. Make sure someone actually notices

Delivering the alert isn’t the end of the job; someone has to see it. When the server receives a panic alert, every manager gets a push notification and an alarm that keeps ringing until someone acknowledges it. A normal notification at 2 a.m. is easy to sleep through or swipe away. An alarm that won’t stop until a person responds turns “delivered” into “handled”.

Lessons for any must-arrive message

• Write it down locally before you try to send it. A message that only exists in a network request is one dropped connection away from being lost.
• Retry until confirmed, and make the server safe to receive the same alert twice, so retries and a second channel can’t create duplicate incidents.
• Have a second channel with different failure modes, and a deadline for switching to it. A few seconds is the right scale for an emergency.
• Require acknowledgement from a person, and escalate until you get it.
• Check the platform rules early. Sending an SMS silently from an app needs a permission that Google Play restricts to a few kinds of apps, and iOS always asks the user to tap Send. Those rules shape how a fallback can work.

Test it where it will be used

An office with good wifi tells you almost nothing about a guard post at night. Test with airplane mode, with data off but calls and SMS on, with a weak signal, after a restart, and with the app closed. Test on the cheaper phones the guards actually carry, since aggressive battery savers on some Android phones stop apps working in the background. And test the whole chain: tap the button, then time how long it takes until a manager’s alarm rings.

The short version

For anything safety-critical, assume the network will fail at the worst moment. Save the alert on the device, retry until confirmed, fall back to SMS after a short deadline, and keep alerting a human until one responds. The button should feel simple to the person pressing it, because all of that is happening behind it.