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.
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.
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