By default, all messages sent on Ably will be stored for 2 minutes on our servers. This allows for clients who disconnect for less than 2 minutes to recover any messages they might have missed, through our History API. The recovering client will receive these messages in the original order they were sent, and this is applicable to both regular channel messages and presence messages.

History representation

However, if your use case requires longer retention of messages, i.e. longer than the default two minutes, you can enable “persisted history”: using both the Realtime and the REST libraries of Ably. If persisted history is enabled for a channel, its messages will typically be stored for 24 – 72 hours on disk.

Enabling persistent history

Every message that is persisted to or retrieved from disk counts as an extra message towards your monthly quota. For example, for a channel that has persistence enabled, if a message is published, two messages will be deducted from your monthly quota. If the message is later retrieved from history, another message will be deducted from your monthly quota.

To enable history on a channel, it is necessary to add a channel rule in the settings of your application dashboard. See the documentation on channel rules for further information on what they are and how to configure them.

Ordering of historical messages

The order in which historical messages are returned by the History API is based on the message timestamp that was assigned by the channel in the region that the message was published in. This ordering is what Ably calls the canonical global order.

It is important to note that this is not necessarily the order that messages were received by a realtime client. The order in which each realtime client receives a message depends on which region the client is in.

Ably preserves ordering for a specific publisher on a specific channel but, for example, if two publishers in regions A and B publish “message 1” and “message 2” simultaneously, then it is very possible that a subscriber in region A will receive “message 1” before “message 2”, but that a subscriber in region B will receive “message 2” before “message 1”.

There are instances where messages will not be in canonical global order:

- Recent messages (less than two minutes old) are retrieved from live ephemeral storage and are still ordered by region. They only appear in the canonical global order if you enable message persistence, which also prevents duplication and missing messages.
- You choose to retrieve historical messages only up to the point at which a client attaches to a channel. You would typically use this approach to bring a subscriber up to date as part of connection state recovery.

Need help?

If you need any help with your implementation or if you have encountered any problems, do get in touch. You can also quickly find answers from our knowledge base, and blog.