How to Fix Missed On-Call Notifications on iPhone and Android
Sources and verification
- Source dates
- Oldest source check: 10 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
Find the last proven step in the notification chain: incident creation, routing, selected responder, channel attempt, provider response and handset receipt. Compare that evidence with the expected behavior before changing phone settings. Test each required channel on the actual device, including its overnight state, and deliberately withhold acknowledgement once to verify a backup responder receives the escalation.
Key takeaways
- Provider acceptance is not evidence that a person heard the page.
- Start with incident and routing evidence before blaming the phone.
- Fallback delivery and escalation need separate tests.
Preserve one missed event
Record the incident identifier, UTC time, expected responder and channel. Find the notification log before retrying repeatedly; retries can obscure which attempt succeeded. Distinguish an incident that never formed from a notification that was attempted but did not reach the handset.
This procedure also applies when investigating xMatters, AlertOps or another provider. A report of a missed page does not establish a product-wide defect. Use that provider's logs and supported device settings to locate the failure.
Follow the evidence
| Last proven step | Next question | Useful evidence |
|---|---|---|
| Source emitted event | Did the integration accept it? | Event ID and ingestion response |
| Incident exists | Was it suppressed or routed elsewhere? | Incident state and route decision |
| Correct route | Who did the schedule select then? | Historical schedule and override |
| Correct person | Was this channel due yet? | Notification rules and attempt time |
| Provider accepted | Did the handset receive or silence it? | Device notification and call history |
Check whether acknowledgement or resolution by someone else stopped later notifications. Do not interpret an intentionally cancelled step as a failed SMS.
Test the actual phone state
PagerDuty's troubleshooting checklist (opens in a new tab) covers permissions, Focus/DND, cellular conditions and blocked or silenced callers. For your app and operating-system version, verify which critical-alert or bypass permissions it actually supports; do not assume every app can override every mode.
Run a planned daytime test with the phone locked and configured as it will be overnight. Compare Wi-Fi and cellular data. Check sign-in state, app notification permission, Focus/work profiles, Android background restrictions and call screening as applicable. Change one setting at a time and record the result.
Do not turn off a managed-device control without involving whoever administers it. Record that constraint and provide a supported alternate channel if needed.
Separate channel fallback from people escalation
An illustrative test policy sends push to the primary, then a voice attempt, then calls the backup if nobody acknowledges. Your timings should come from your incident response requirements. A voice fallback to the same unreachable phone is not the same as handing responsibility to another person.
Test push, SMS and voice individually if your policy relies on them. Then test their configured sequence. Withhold acknowledgement with responders informed, and record the backup's actual receipt and ability to take ownership.
Close the issue with a repeatable record
Keep expected versus actual recipient, attempted channel, provider outcome, handset outcome, acknowledgement and escalation times. A support report with these facts is more useful than “notifications don't work.” Redact phone numbers and tokens in public copies.
Re-test after the fix under the original failing conditions. Then follow the broader end-to-end paging procedure to verify that a direct device test did not bypass a broken production schedule.
Run a mobile acceptance test before switching providers
Prepare a device matrix for the responders who will use the replacement: phone model, released operating-system version, app version, managed profile, overnight mode and relied-on channels. Do not generalize a successful test on an administrator's phone to every device in the rotation.
| Test condition | Evidence to keep |
|---|---|
| Locked screen in normal overnight mode | Visible or audible receipt on the actual handset |
| Wi-Fi unavailable, cellular data available | Required channel still reaches the responder |
| App signed out or permission denied in a demo account | Failure becomes visible and the backup process works |
| Primary deliberately does not acknowledge | Backup receives and accepts the test incident |
| Required phone or SMS channel | Its own delivery and sound behavior, independently of push |
PagerDuty's mobile settings documentation (opens in a new tab) distinguishes platform-specific notification controls. A permission that allows high-urgency push through a mode does not establish the same behavior for voice or SMS, and a different provider may expose different controls.
Generate a pager test plan, inform all test responders, and use a disposable incident with downstream customer automation disabled. Restore any temporary test settings. Repeat the original failing condition after a fix and save observed receipt, acknowledgement and escalation times. A passing matrix covers those devices and conditions on that date; add a retest trigger for app, operating-system or managed-policy changes.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Frequently asked
- The provider says delivered. Is the problem definitely my phone?
- No. Clarify what that delivery state means for the channel. Compare provider records, handset receipt and whether the user actually heard or saw it.
- Should I acknowledge during the escalation test?
- For one planned test, deliberately leave the primary step unacknowledged so the backup path can fire. Tell both responders and use an isolated test incident.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- Notification troubleshooting — PagerDuty. Checked 10 September 2026.
- Mobile app settings — PagerDuty. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS