How does Ably count and bill for messages?

Ably accounts are priced based on the number of messages, the total bandwidth used, and the number of concurrent connections within any calendar month.  Find out more about all account limits you should be aware of.

The count of messages is calculated as follows:

• Publish / Subscribe

  • Every message published on a channel is counted as one message
  • Every message received on a channel is counted as one message. For example, if a client publishes a message on a channel with 10 clients attached to the channel, then that will count as one message published, and 10 messages received
  • Note: 
    • Client-side filtering of messages has no effect on message counting as all messages published on a channel are received by the client and the client-side filtering offered per channel is only a convenience provided for developers. See the realtime subscribing to messages documentation.
    • If echo messages is enabled (the default setting), then every message published on a channel using a realtime client is also echoed back to that client and will thus count as two messages (one published, one received).  See the echoMessages attribute of the client options documentation if you wish to disable automatic message echoing.
    • If a client is attached to a channel for which it does not have the `subscribe` capability (see https://www.ably.io/documentation/general/authentication#capabilities-explained ), then it will not receive (or be charged for receiving) any messages. This can be useful if you have a client which only needs to publish, not subscribe.

• Presence

  
  
  • Every presence event published is counted as one message i.e. if a client enters, updates, or leaves a channel, that counts as one message.
  • Every presence event received on the channel is counted as one message. For example, if a client enters a channel and there are 10 clients attached to the channel (including the client that entered), then that will count as one message published, and 10 messages received.
  • Note: 
    • Similarly to normal messages, client-side filtering has no effect on presence message counting. 
    • Unlike normal messages, the echoMessages client option has no effect on presence messages, which are always echoed so as to allow the entering client to know when they are themselves present and to rejoin the presence set when they need to.
    • If a client is attached to a channel for which it does not have `subscribe` capability (see https://www.ably.io/documentation/general/authentication#capabilities-explained ), then it will not receive (or be charged for receiving) any presence messages -- with the exception of its own presence messages, which it will always receive, per the previous bullet point. This can be useful if you have a client which only needs to be present, not receive presence messages.
    • People may be surprised by how many messages they can publish and receive in a short amount of time when using presence due to the n-square problem of many subscribers and publishers on the same channel. Find out why we impose standard limits on presence channels to help address this and what strategies can be used to reduce the number of messages received, 

  • Presence get requests via REST or REST SDK

    • Requests to get instantaneous presence - https://ably.com/docs/api/rest-api#presence will count as one Ably message for each user returned in the presence set (and one API request)
    • Requests to get presence history - https://ably.com/docs/api/rest-api#presence-history will count as one Ably message for each history entry returned (and one API request)
    • Batch presence requests follow the same, one Ably message for each user returned from the included channels in the request (and one API request)

• Metadata and statistics

  • Request via REST

    • At present, REST requests to retrieve channel metadata (such as single channel status and occupancy, or channel enumeration) will not count towards your message limit. However, we may in future consider charging for these requests if the volumes of these requests is considerable.  Get in touch if you want to discuss your requirements.
    • REST requests to retrieve history for log event channels will count as one message per event returned 

  • Log Events

    • Messages published on [meta]log will not count towards your message limit.
    • Messages subscribed on [meta]log will not count towards your message limit.
    • Messages published on [meta]log:push will not count towards your message limit.
    • Messages subscribed on [meta]log:push will not count towards your message limit.

  • Lifecycle events

• • • [meta]connection.lifecycle subscription counts as one message towards your message limit per lifecycle event e.g a message for each connection.opened or connection.closed and transport.opened or transport.closed event

    • [meta]channel.lifecycle subscription counts as one message towards your message limit per lifecycle event e.g a message for each channel.opened or channel.closed and channel.region.active or channel.region.inactive event

  • Integrations

    • Every channel lifecycle event published over Reactor will count as one message

  • Statistics

    • [meta]stats:minute subscription counts as one message towards your limit per event 

• History

  • Every message stored using our history feature counts as one message
  • Every message retrieved from history count as one message per message received
  • Every message retrieved from history counts as one API request 

• Ably Queues, Events (WebHooks & Functions) and Firehose

  • Every message published to a Queue, WebHook, Function or Firehose will count as an additional message. For example, if you publish a message on a channel that is in turn republished to a Reactor Queue, that will count as two messages.

• Push Notifications

  • Every push notification delivered to a device counts as one message.  The count is the same irrespective of whether the message is broadcast via our channel fan-out functionality or published directly using the publish API.

• Bandwidth

  • The size of each message published is calculated based on the size of the name, data and extras fields of your message or presence messages.
  • The amount of bandwidth allocated to your account is calculated using the total number of messages in a month multiplied by the allowed average message size (typically 2KiB unless agreed separately with your account manager).  For example, on a free account with 6 million messages and an average message size of 2KiB, the total bandwidth included in the month is 11.5GiB.
  • Every message published that is over 2KiB counts as more than one message.  For example, a 16KiB message published is counted as 8 messages when published, and if received 10 times, is counted as 80 messages received.

• Time and Ping

  • Neither count towards message counts

Further reading

• Find out about all connection, channel, message and rate limits on Ably accounts
• If you received an email about hitting a limit, find out what this means and what you can do about it
• Find out how to upgrade your account
• Get in touch if you would like to review your account limits or need help upgrading.

If you need any further help, please reach out on our support portal and we will be happy to help you.