The failure mode everyone knows
A P1 fires at 3 AM. The phone is on silent — because it is always on silent. Vibration maybe, sound nothing, and the incident is discovered the next morning by triage instead of at 3:01 by a human. We have lived this failure ourselves, and users have reported it to us about other tools: "I felt it vibrate, but there was no alarm."
Most alerting apps lose this fight for structural reasons, not because their developers were careless. Modern mobile OSes are engineered — aggressively — to stop apps from making noise. A paging tool that treats sound as a notification setting will lose to the operating system. This post is the exact mechanism OpsPing uses on both platforms, including the parts we can't control.
Why ordinary push loses
Three layers stack against a normal alert:
First, notification sounds are mode-muted. On Android, sounds attached to a notification channel are suppressed by silent and vibrate ringer modes regardless of the channel's importance or its audio attributes. We verified this on-device: a max-importance channel with an alarm audio attribute still stays quiet in vibrate mode. A pager whose sound is "the notification sound" is a pager your own phone settings can disarm.
Second, JavaScript is not a delivery mechanism. Cross-platform frameworks process push payloads through a headless JS task. JS startup can lag FCM receipt by seconds — or drop the event entirely. We watched it happen twice on physical devices during development: the push arrived, the vibration pattern ran, and the alarm never started because the JS task never executed.
Third, background push is best-effort. OS budgeting delays or coalesces background work precisely when a saturated network is delivering an incident wave.
iOS: critical alerts, not notifications
Apple grants a Critical Alert entitlement to apps whose notifications are safety-relevant — medical, home security, and on-call paging qualify. A critical alert plays its sound at full volume with the mute switch on and Do Not Disturb active. That is the entire trick, and it is why OpsPing's iOS app requests the entitlement and maps priorities to per-severity critical sounds: a P1 does not sound like a P4.
One iOS-specific trap catches nearly everyone with an Apple Watch: notification mirroring. With mirroring on, the watch accepts the alert and the phone can stay silent — the watch taps you, the phone never rings, and deep sleep loses to a wrist tick. The fix is a setting, and it is documented step by step in our Apple Watch guide: turn off OpsPing mirroring so the iPhone — the device with the speaker next to your bed — handles critical alerts.
Android: the channel trap, and the alarm that isn't a notification
Android since Oreo routes every notification through a channel, and — as above — ringer modes mute channel sounds. So OpsPing's P1 channel is intentionally silent. That is not a bug or an omission; it is the design working around the platform. The channel still carries max importance, bypasses Do Not Disturb, and vibrates. The sound is something else entirely:
The app plays the alarm itself — a native MediaPlayer loop on the media stream, capped at 120 seconds. Media-stream playback is what music and podcasts use, and Android does not mute it in silent or vibrate mode. The result: a P1 sounds like an alarm clock no matter where the ringer switch is. Per-severity sounds map P1–P5, so an unattended P3 does not scream like a database fire.
When the app is cold
An alarm that only works when the app is warm is a demo, not a pager. OpsPing's Android build registers a native FirebaseMessagingService — a subclass with a higher-priority intent filter than the framework default — that starts the media-stream alarm inside the native layer, whether or not any JavaScript ever executes. The history here is instructive: before this service existed, cold-start deliveries ran the vibration pattern and dropped the alarm when headless JS failed to start. The native receiver also catches everything, so an exception in one delivery path can never kill the alarm that is already playing.
Since September 2026 the player pauses when you open the app and hands control to an engagement loop: acknowledging stops everything, an unhandled alarm re-arms, and backgrounded unacknowledged P1s re-page. Snooze stops the loop. The escalation policies you configured do the same at the platform level — an unacknowledged P1 walks the chain until a human owns it.
What we can't control
Honesty requires the limits:
The app must be installed. Critical alerts and the native alarm are app capabilities — a web dashboard cannot wake anyone, which is why web-only evaluations systematically miss this layer. Android keeps hardening. Recent Android releases partially mute background playback and ignore background volume changes; we detect the ignored volume changes and log them, and playback continues at wherever the OS permits. And delivery rides FCM and APNs — the same transport every mobile app on both platforms uses.
Test it, don't demo it
This layer is exactly why we tell evaluators to test on a real, silenced phone: install the app, put it in silent (iOS) or vibrate (Android), send a test P1 from the mobile setup guide, and compare what happens to your current pager's behavior with the same settings. If you are evaluating against other tools, our comparison pages list mobile delivery as a first-class row for this reason.
— The OpsPing team