Preparing for use of the Throttle Service


This feature is available on certain contracted plans. Please contact your Airship Account Manager about enabling this service with your account.


The purpose of this document is to do the following:

  • Describe what Throttling is
  • Determine the Throttle Rate for your application
  • Considerations and best practices when Throttled

What is Throttling?

Throttling is a service provided by Airship that is designed to alleviate any load issues that systems tied to your Airship project may incur from sending large amounts of notifications. By design, the throttling service will slow down notifications that are sent from Airship but is not a guarantee of a rate of notifications being sent. This service is an excellent temporary resource to leverage while building out more resilient backend services to handle this traffic.

The Throttling service is currently available for application (iOS, Android, Amazon)  and web notifications. Email, SMS, and Open channels are not able to be throttled at this time.


Important details about the throttling service

  • The throttle rate is applied at the project level, meaning ALL pushes adhere to the specified rate.
  • The throttle rate is determined by the number of pushes per second.
  • For best results, the audience should be greater than 1,000,000 users.
  • Subsequent pushes will be queued behind pushes in progress (please see the best practices section below).
  • Messages are sent in batches of 1000 at a time. If the throttle rate applied is lower than 1000 per second, the throttling service will artificially create the lower send rate by increasing the amount of time between batches sent.
  • Ideally, The slowest possible throttle rate applied should allow for a broadcast push (entire audience) to complete delivery in less than 8 hours. 
  • The throttle rate for push notifications does not define a specific send rate, but rather a maximum rate amount. Send rates can fluctuate lower than the given rate.

Determining the Throttle Rate

Depending on the configuration of your app, it is strongly recommended that the throttle rate be determined in partnership with your backend development teams. 

The throttle rate, or specified rate of sending notifications, can best be determined by understanding the maximum sustained level of app activity that your systems can handle. It's important to note that this is not necessarily related to the number of pushes sent, but rather the extent to which resources (e.g. API calls, video streaming, etc.) are utilized, and how much push notifications play a factor in this traffic. Some other factors to consider about the send rate:

 Message Send Rate vs. Message Delivery

  • Messages often are passed through many systems and networks before they reach a device. This can further affect the rate of delivery for messages sent to your users.

Message Delivery vs. Message Open Rate

  • Normally, only a portion of messages delivered will result in creating load on the backend systems as not all delivered messages are opened at the time of delivery. Typical conversion rates from opens typically range from 5-30% of the delivery rate.
  • The exception to this would be background pushes, which could create a higher volume of traffic relative to the number of pushes sent, and greater sensitivity to push volume.


Considerations and best practices when Throttled

Due to the throttle rate being applied at the project level, there are some factors that will need to be taken into consideration when formulating your push notification strategy. Some of these are mentioned below: 


Expiring Push Notifications

Due to the throttling system reducing the send rate of your project, it is recommended that pushes be sent with expiration to avoid any inappropriate delivery times. There is a key difference in the handling/concept of expiration between iOS and Android which is outlined below:

  • iOS
    • iOS handles the defined expiration as a "do not deliver" after this date/time. Any pushes handed off to the Apple Push Notification Service (APNS) with an expiration will be dropped if received after the expiration time (see: Sending Notification Requests to APNS).


  • Android
    • Android takes the defined expiration time and converts the time into a window for delivery. To summarize, messages handed off are given a "time to live" (TTL) window (in a number of seconds) to deliver from when the message is received from Airship. While this is typically not a cause for concern in any other case, with a throttled message the expiration start time begins when handed off to Firebase Cloud Messaging (FCM), which can mean later than anticipated deliveries. When planning out large push campaigns its important to be aware of this behavior to avoid notifications being delivered at inappropriate times to your Android audience. 


Scheduling notifications with Throttle enabled

Scheduled notifications within Airship are a guarantee that notifications will not deliver before the specified date/time but is not a guarantee of delivery time. Due to the asynchronous nature of the throttling service, a push that is scheduled to deliver can be delayed in sending if queued behind another push.

Optional setting for time-sensitive push notifications  

This option is only available for messages being sent using the API at this time

At times you may need to send out time-sensitive or urgent notifications to your users. Through the API, you can remove the throttle rate on a per-push basis using the no_throttle flag.

As an example:

    "options": {
        "no_throttle": true
    "audience": "all",
    "device_types": [
    "notification": {
        "alert": "This is message is un-throttled."


Notifications sent using this flag as outlined in our Push Object documentation will bypass any currently queued messages to send as soon as possible to your audience.

Contact Support

If you have additional questions or require further assistance with determining the most appropriate throttling rate for your project please reach out to the Airship Support Team at

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