What is Recovery alert?

Most alerting systems tell you when something goes wrong and then go quiet. You get “device left the zone” and nothing more. Whether the situation resolved two minutes later or is still ongoing an hour on, you have to open the app and look.

A recovery alert closes that loop. When the condition that triggered the alert returns to normal, you get a second notification saying so.

Why the missing all-clear is a real problem

The gap sounds minor and is not, because of what it does to trust.

An alert without a resolution forces manual checking. You are notified that a child left school grounds, and now you must open an app to find out whether they came straight back. Do that a few times and the alert stops feeling like information — it feels like a prompt to go and do work.

The predictable outcome is that people stop reacting to alerts. If most excursions turn out to be nothing, and finding that out costs a manual check every time, the rational response is to check less. Which is exactly the behaviour you did not want.

Recovery alerts make the notification stream self-contained. Two messages — “left at 14:12”, “returned at 14:19” — and you never opened anything.

Why most systems do not send them

Sending a recovery alert requires knowing that you previously alerted. That sounds obvious, but a system that only tracks physical position has nowhere to store it.

If all you keep is “the device is inside the zone”, you cannot distinguish between a device that just returned after an alert — where a recovery is warranted — and a device that has been sitting inside all day, where a notification would be nonsense. You need a second piece of state describing the notification history, not the physical one.

Systems that skip alert debouncing usually skip recovery alerts too, for the same underlying reason: they never separated those two ideas.

What Geoblip does

Each device-zone pairing carries an alertStatus of ok or alerting, independent of the physical inside/outside flag. That single field makes recovery possible.

When a device re-enters a zone, Geoblip checks the status:

• If the status is alerting, an exit alert is outstanding. A recovery notification is sent, the original exit alert is marked resolved with a timestamp, and the status resets to ok.
• If the status is already ok, the device was never alerting — it drifted back, or was always inside. No notification. Nobody wants “your device is still where it should be.”

That conditional is the whole feature, and it is only expressible because the notification state exists separately.

Schedule-end: the other kind of resolution

There is a second way an alert stops being relevant. If a device leaves during a monitored window and is still outside when that window closes, the alert has not resolved — but it is no longer being watched.

Geoblip sends a distinct schedule-end notification for this case rather than pretending it is a recovery. The two mean genuinely different things:

Notification	Meaning
Recovery	The device came back inside the zone
Schedule end	Monitoring stopped while the device was still outside

Collapsing them would be misleading. “All clear” and “we stopped watching” are not the same message, and a parent reading the second as the first is exactly the kind of error worth engineering against.

Alert lifecycle

A complete excursion produces a readable history:

1. Device exits during an active window → exit alert, status becomes alerting
2. Device drifts across the boundary a few times → suppressed, no notification
3. Device genuinely returns → recovery alert, exit alert marked resolved, status back to ok

Or, if it does not return:

3. Window closes with the device still outside → schedule-end alert, status reset to ok so tomorrow’s window starts clean

Either way the alert is closed and the next window behaves correctly. See exit alert for what opens the sequence, and geofencing for the wider picture.

Last reviewed 7 August 2026.