Troubleshooting Push Delivery

When troubleshooting push delivery, it helps to have an understanding of the path that notification takes from the time a request is made with Airship to the point at which it appears on a device.

Notification Delivery Path:

  1. A request to send a push notification is made to Airship from the API or Dashboard.
  2. Airship processes the push request and determines which active devices that the notification should be sent to.
  3. Airship passes requests to the appropriate service provider (FCM, APNS, etc) as individual push messages addressed to each device.
  4. The service provider performs the delivery of the push notification to actual devices.
  5. This notification passes over the Internet to arrive on the device usually over WIFI or a cellular data network.
  6. The client app on the device handles the message as appropriate for the platform, context, and message type.

Common issues and resolutions for push notification delivery:

Cellular connectivity can be unreliable:

  • Device connectivity can be spotty.  If a device is having trouble connecting to a data network, it may not immediately retry to connect. This may result in delays. Restarting a device can help force it to reconnect.  You can resolve this issue by providing a stronger signal to the device often by moving the device's physical location.

Certain networks may restrict access to the ports used to deliver notifications:

If your device is connected to a WIFI network that blocks port 5223 and/or 5228-5230, you will likely not receive any Apple or Google push messages.  Please unblock these ports on your firewall to receive push notification traffic.

  • APNS uses port 5223
  • FCM uses ports 5228 - 5230

Polling for notifications may have different behavior when only wifi connectivity is available:

  • When a cellular connection is not available (or for wifi-only devices), a convenient connection to the push service may not be available. In this case, the polling interval can be as long as 15 minutes.  You may have better luck when plugging the device into it's charging cable. This can provide more power to the phone so that it engages its' radios more frequently.

Apps in the foreground may not show notifications:

  • Apps may handle push notifications differently when they are in the foreground. The notification may be received by the device but not be visible on screen. Airship will not show a standard notification when the app is in the foreground by default. Delivery can still be confirmed in device logs.  Customers can customize their app implementation to display notifications while the app is in the foreground.

Push notifications may be disabled in system settings:

  • Make sure that the app has opted-in to push and that Quiet Time or Do Not Disturb settings for the app are not turned on.

Try general device connectivity troubleshooting:

  • Restart the device
  • Enable airplane mode for 15 seconds, then disable it to force a reconnection to all network services.
  • Disable cellular connectivity to isolate the issue with only one method of connection

Confirm the device is included in the segment requested:

  • If the push was sent to a segment, confirm that the device has all needed Tags registered to is. This can be done using the Device Lookup page on the Airship dashboard at
  • If the push was sent to a Named User, confirm that Channel ID has that registered to it.
  • If you are using an android device, retrieve your Channel ID to make sure that you are not targeting an inactive channel

Submitting a Support Request:

If needed, Airship support can confirm that notifications were handed to the push platform service providers for final delivery to the device in most cases.

To do this, we require some additional information to be included in the support request:

  • Your app's App Key. Please do not send us your app secret or master secret.
  • The push_id returned by our Push API or a link to the Web Dashboard's reports for the push in question.
  • Channel IDs for devices that did not receive the push as expected.
  • Explain the troubleshooting steps that have already be done

Related Content

Was this article helpful?
0 out of 1 found this helpful
Submit a request