When Expo push notifications stop working, find the last stage that has evidence of success. A token, an accepted push ticket and a visible notification prove different things. Trace one controlled message through registration, your backend, Expo, the platform provider and the app before replacing credentials or rewriting the integration. This guide gives an investigation order, a symptom table and a report your developer can reproduce.
Key takeaways
- Trace one authorized test message and record the installed build and environment.
- Check registration, ticket, receipt, presentation and tap behavior separately.
- Use the returned error to choose the next experiment; avoid broad credential resets.
- Keep a sanitized evidence record and turn the verified fix into a release check.
Start with one recipient and one reproducible message
Choose a test account and a harmless message that you are authorized to send. Record the installed build, platform, time and app state. Avoid sending a campaign to discover whether the integration works. The useful question is narrower: where does this one message stop? First distinguish remote push, which starts outside the device, from a locally scheduled reminder. A local reminder can work while remote delivery fails, so it is a useful comparison but cannot validate the remote path.
- Write the expected result: a banner while the app is closed, a foreground update, or a tap that opens a specific screen.
- Use a test record with no customer names, payment details or sensitive message content.
- Keep one investigation ID across your application logs and delivery records. Redact recipient identifiers in shared reports.
- Change one variable at a time. If you change the build, payload and credentials together, a successful retry will not tell you which change mattered.
Verify the installed app before investigating the server
Treat the app on the device as the starting point. Confirm its application identifier, build version, Expo project and notification permission state. Compare those details with the backend environment that selected the recipient. A token copied from another installation or a staging account can make a correct sender look broken. Expo's setup guide covers the notifications plugin, projectId, permission and platform credentials. It currently supports physical devices and eligible emulators or simulators; Android needs Google Play services, and iOS Simulator support requires the documented Xcode, macOS and iOS versions. A physical device running the intended release remains a useful final comparison.
- Record whether this is Expo Go, a development build or the distributed release. Do not write only 'works on my phone'.
- Compare the token registered by this installation with the recipient selected by the backend, using a protected internal identifier rather than pasting the full token into a public ticket.
- If native notification configuration changed, verify that the installed binary contains it. A JavaScript update alone does not replace native configuration.
- If the issue began during an SDK migration, reproduce it in the matching build before attributing it to the SDK version.
Expo: current push notification setup and supported test environments
Separate Expo acceptance from delivery to the device
A successful ticket means Expo accepted the message; its receipt reports the subsequent handoff to APNs or FCM. Even an 'ok' receipt does not establish that a person saw a banner. Store the ticket ID and inspect the receipt before moving to presentation behavior. Follow the specific returned error instead of retrying every failure. For DeviceNotRegistered, stop using that token until the app registers again. Use bounded retries for temporary failures, with the sending procedure and error definitions in Expo's documentation as the authority.
| Observed symptom | Evidence to collect | Next controlled check |
|---|---|---|
| No usable recipient token | Registration result, project and installed build | Resolve registration and recipient mapping before testing delivery. |
| Request or ticket error | Status, error code and sanitized payload shape | Check the exact error against the sender configuration and message fields. |
| Ticket accepted; no receipt checked | Ticket ID and the receipt lookup result | Complete the provider handoff investigation before changing the app UI. |
| Receipt reports invalid credentials | Affected platform, project and credential association | Review that environment's signing and push configuration; avoid unrelated key rotation. |
| Receipt ok; no visible banner | App state, permissions, channel and presentation behavior | Compare one foreground and one background test on the same installation. |
| Banner arrives; tap opens the wrong screen | Response handler, session state and target record | Trace navigation after authentication and permission checks. |
Investigate presentation separately from transport
Once the handoff evidence is sound, test what the operating system and app do with the message. Expo distinguishes notification receipt, foreground presentation and the user's response. Check the foreground handler and the response listener against your intended behavior. Run a small matrix: app open, app in the background, and app opened from a notification. Record the actual result in each case. On Android, include the notification channel in the comparison; a transport result alone cannot establish presentation settings.
- Separate 'the app received an event' from 'the system displayed a banner'. Give each a distinct result in the report.
- For a tap, check both a warm session and a session that needs sign-in. Preserve the intended destination while authentication completes.
- Verify that opening the destination still checks access to the record. A notification payload should not grant permission to read it.
- Define a useful fallback for deleted, expired or inaccessible records instead of leaving the user on a blank screen.
Expo: handling received notifications and notification responses
Find where your notification journey breaks.
Share the affected build and sanitized delivery evidence. We can review registration, backend delivery and the screen your users reach after a tap.
When development works but the release does not
Compare the two installations as separate environments. 'Same code' is not enough evidence that the native build, account, project, credentials and backend selection match. Expo's FAQ identifies build and credential differences as an important troubleshooting area. Make a two-column record for the working and failing installations, then investigate the first meaningful difference. Rebuilding can be the correct next step when native configuration changed; it should follow that finding rather than serve as a repeated guess.
- Compare application ID, version, build identifier, project and backend environment.
- Confirm that a newly registered token reached the correct authenticated account record, and that logout or account switching does not leave it associated with the wrong user.
- Check whether the problem affects all recipients, one platform, one release, or one installation. Those are different scopes of failure.
- Keep a short change log with each experiment and its result, including unsuccessful attempts. It prevents the next developer from repeating the same reset cycle.
Give your developer a report they can act on
The following is an original report template, not a production incident or a completed device test. Fill it with your own protected evidence. Keep raw credentials, full tokens and customer payloads out of shared documents. A report is ready for a handover when another developer can identify the installation, follow the same experiment and locate the last successful boundary without asking for a screen recording of the entire app.
Notification investigation record
Use for a single controlled reproduction; replace the bracketed fields.
Expected result: [banner / in-app event / tap destination]
Test time and timezone: [time]
Installed version and build: [version, build identifier]
Platform, OS and app state: [details]
Environment and project reference: [non-secret internal reference]
Recipient record: [redacted internal ID]
Registration result: [success or error; no full token]
Sender request and ticket: [internal trace reference, status]
Receipt: [status, error code, lookup time]
Presentation and tap result: [observed behavior]
Last confirmed successful stage: [stage]
One next experiment, owner and result: [details]Budget for ongoing mobile app compatibility and release checks
Turn the fix into a release check
After finding the cause, preserve the smallest useful regression check. Registration, recipient association, a delivery record and a valid tap destination belong in the acceptance criteria when notifications are part of the product's core workflow. Document which environments and app states were actually checked. This guide supplies an investigation method; it does not claim that your app, its credentials or its devices have been tested. If you need help, send Mubbits a sanitized description of the failing stage and the affected build so the review can start with evidence.
Frequently asked questions
Does an Expo push receipt with status ok prove delivery?
It proves that APNs or FCM accepted the handoff, not that the device displayed the message. Continue the investigation with device state, permissions and presentation behavior.
Should I regenerate all credentials when push stops working?
Start with the failing boundary and its returned error. Check the affected app, platform and environment before replacing keys. Broad rotation can disrupt other builds and makes the original cause harder to identify.
Can I test Expo push on an emulator or simulator?
Expo currently documents support for eligible Android emulators with Google Play services and iOS Simulators meeting its toolchain requirements, as well as physical devices. Check the current setup guide and compare the intended release on a physical device before signing off.
What should I send an agency to investigate the problem?
Share the affected build, platform, app state, expected result, sanitized ticket and receipt outcomes, and the last successful stage. Start without production credentials, full device tokens or customer notification content.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.