Why "Repeating Until Acknowledged" Beats a Single Push Notification
A phone on silent will happily eat a single push notification without a trace. So will Do Not Disturb, or a dead battery that recovers after the alert window has already passed. So will the ordinary chance that someone doesn't glance at their phone during the sixty seconds a notification banner is visible, before it disappears into a notification center nobody checks until morning.
Treating a paging system like a messaging app is the core problem here. A single notification is a best-effort delivery, not a guaranteed one — even the IETF standard defining how push notifications get delivered only specifies getting an event to the user's device, not confirming a human ever saw it. For a group chat, best-effort is fine — a missed message gets seen eventually. For an incident that's actively affecting customers, "eventually" is the entire problem.
What "repeating until acknowledged" actually means
A proper page doesn't fire once and stop. It fires, waits a short interval, and if nobody has explicitly acknowledged it, fires again — and keeps firing on that interval until someone does. This sounds like a small mechanical difference from a single push notification. But it changes the failure mode entirely: instead of one shot that either lands or doesn't, there are repeated shots until one of them does.
The repeat-until-acknowledged mechanic is also why acknowledgment has to be an explicit action, not an inferred one. A notification that stops repeating just because it was displayed on a lock screen isn't actually confirming anyone saw it. It's confirming the OS rendered it, which isn't the same thing.
How many times should an alert repeat before you call someone unreachable?
There's no universal number, but most paging setups repeat every one to five minutes for a defined window — often somewhere in the fifteen-to-thirty-minute range — before treating the primary responder as unreachable and escalating to the next person. The exact interval matters less than having one defined at all. A team that hasn't picked a number defaults to whatever the tool ships with, which may not match how urgent their actual incidents are.
Shorter intervals make sense for anything customer-facing and revenue-affecting, where a few extra minutes of downtime is expensive. Longer intervals make more sense for something like an internal batch job that's annoying but not urgent — repeating every thirty seconds for that kind of alert just trains people to silence it faster.
A hard ceiling on the total escalation window is also worth setting, separate from the repeat interval. A page that keeps repeating for two hours before anyone else gets pulled in isn't protecting the on-call person — it's just delaying the moment someone realizes the primary responder needs backup. The repeat interval controls how persistently one person gets paged; the ceiling controls how long the team waits before treating them as unreachable.
Does a normal push notification wake someone up?
No — a standard push notification respects the phone's silent settings by design. That's exactly correct behavior for a regular app, and exactly wrong behavior for a page that needs to wake someone up. This is why critical alerting tools use a different delivery mechanism. iOS critical alerts and Android's alarm-style delivery are specifically designed to bypass silent mode and Do Not Disturb, playing at full volume regardless of the phone's settings.
PingParrot pages use this mechanism by default for anything marked high-priority. Combined with repeat-until-acknowledged behavior, a page isn't just louder than a notification — it's also persistent in a way a single alert can never be.
The escalation policy is the safety net behind the repeat
Repeating alerts solve the "missed it the first time" problem. They don't solve the "genuinely unreachable" problem — a phone that's off, or a person who's truly unavailable. That's what an escalation policy is for. If the repeating alerts to the primary on-call person go unacknowledged past a defined threshold, the page moves to the next person in the chain automatically.
The two mechanisms work together, not as alternatives. Repeating alerts maximize the chance the right person catches it. Escalation is the backstop for the case where they genuinely can't.
One edge case worth planning for: what happens when the second person in the chain is also unreachable, and the third. A rotation with only one layer of backup looks fine until the night the primary is asleep with their phone off and the backup is on a flight. Building in at least two escalation layers — not just a single backup — is cheap insurance against a scenario that's rare but not actually unlikely over a long enough time horizon.
Why this matters more than most feature comparisons
When teams compare paging tools, the conversation usually centers on integrations, pricing, and dashboard design. All of that is real, but it's secondary to the one job the tool actually has to do reliably: get a human's attention during an incident. A tool with a beautiful dashboard and a single-shot notification will lose to a bare-bones tool with a genuinely persistent, escalating alert, every time it actually matters.
If you're evaluating a paging tool, this is the first thing worth testing directly. Don't just read about it — trigger a real test alert at night, phone on silent, and see whether it actually wakes you up.