Notification problems often look random because several layers make independent decisions: the sender creates an event, an app receives it, the operating system classifies it, focus rules suppress or defer it, and another linked device may become the destination. A change log connects those decisions to the first missed, late, duplicated, or excessive alert.
Define the notification contract
For each affected alert type, record the sender, recipient account, app, device, channel or category, expected urgency, expected surface, sound or vibration, lock-screen behavior, and acceptable delay. State the symptom precisely: never generated, delivered silently, placed only in history, delayed, duplicated, shown on the wrong device, or blocked during a focus period.
Use a fictional test event. Do not expose message content, one-time codes, medical details, or customer data in screenshots or shared logs. Preserve the original time and device time zone.
Build the change timeline by layer
List recent app and operating-system updates, account changes, permission prompts, notification-category changes, battery restrictions, focus schedules, wearable pairing, device migration, quiet hours, priority exceptions, sender rules, and network changes. Include the last known-good event and the first confirmed failure.
Android Help's notification controls describe per-app settings and, on supported devices, history for snoozed, recently dismissed, and recent notifications. Because menus and availability vary by device, record the observed setting rather than assuming every Android phone exposes the same control.
Check suppression before blaming delivery
Inspect global notification permission, per-app permission, per-category settings, sound, lock-screen visibility, banners, badges, priority, and focus or Do Not Disturb. Microsoft's Windows notification guidance documents app-level banners, notification-center presence, sounds, lock-screen content, priority, automatic Do Not Disturb conditions, and selected priority apps.
On Apple devices, notification routing may change with device state. Apple's iPhone and Apple Watch guidance explains that notifications normally appear on either the watch or phone rather than both and recommends checking Focus settings on linked devices. That makes “missing from the phone” different from “not delivered anywhere.”
Run a controlled delivery matrix
Send one invented test event at a time and record sender acknowledgement, server time if available, device receipt, visible surface, sound, and history entry. Test the app foregrounded and closed, device locked and unlocked, focus off and on, Wi-Fi and cellular where appropriate, primary and linked device, and one unaffected alert category.
Change only one setting between tests. If the event appears in history but not as a banner, inspect presentation and focus rules. If the sender never records generation, inspect its trigger. If one device receives it while another does not, inspect routing, account, and device-specific permissions. If all users fail, look for sender or service changes.
Make the smallest reversible repair
Restore one permission, category, priority exception, focus schedule, account link, or sender rule. Record the previous value, new value, owner, reason, time, scope, expected result, and rollback. Avoid turning on all alerts as a permanent fix; that can create alert fatigue and hide the original classification problem.
Do not disable security notifications, emergency alerts, privacy controls, or organization policy without explicit authority. If reinstalling an app would remove local data or authentication evidence, back up and document before acting.
Verify usefulness, privacy, and recurrence
After the repair, test urgent and ordinary alerts, quiet hours, locked-screen redaction, linked-device routing, sound, accessibility cues, notification-center history, and dismissal synchronization. Confirm that the fix did not re-enable promotional or low-value alerts that users intentionally suppressed.
Close the change log with the confirmed layer, supporting evidence, repair, verification matrix, remaining exceptions, and next review. Useful prevention may include a documented priority taxonomy, owner for each alert type, periodic focus-rule review, post-update canary test, and a privacy-safe diagnostic checklist. The problem is resolved when the intended person receives the right signal on an appropriate surface at the promised time without unnecessary exposure or noise.
Sources
- Control notifications on Android — Android Help
- Notifications and Do Not Disturb in Windows — Microsoft Support
- How to get notifications on your iPhone and Apple Watch — Apple Support