A channel can keep a short backlog. It lets a screen open with context (the last 50 chat messages) and lets a client that lost its connection catch up.

Turn it on in Studio

Services → Realtime → Channels → your rule: set History depth to how many messages to keep (0 to 1000). With none set, nothing is kept. For messages that must survive a restart, set Kind to Durable and choose Retention (seconds), how long a durable message is kept before the sweep purges it. Under Settings, Messages kept for latecomers sets the default.

Load recent messages

Each message has a seq that increases along the channel, so you can order them and remember where you stopped. A good chat screen:
  1. Subscribes, so new messages start arriving.
  2. Loads history.
  3. Shows history first, then live messages, skipping any id it already has.

Catch up after a disconnect

Connections drop. The client reconnects by itself. Ask it to replay what you missed:
After each reconnect the client fetches up to that many recent messages and delivers the ones you didn’t get, once each (duplicates are removed by message id). With replay unset, only messages sent while you were connected are delivered. Replay is bounded by the channel’s History depth. If someone was away longer than that covers, reload the screen’s data from your records.

Access

Reading history needs the same permission as subscribing. If the Subscribe policy refuses someone, they can’t read the backlog.

History is not storage

For anything people expect to find tomorrow (chat logs, orders, notifications), save a record (Database) and use the channel to announce it. Then a missed message costs nothing: the app reads the record.

See it in Studio

In the Playground, join a channel; the messages kept for latecomers appear when you join. Overview shows how many messages were published and delivered.

Channel rules

History depth and retention.

Live records

Data without managing messages.