Session Replay

How it works#

When captureReplay: true (default), Reliable starts an rrweb recorder on init. rrweb takes a full snapshot of the page and then records changes to it: DOM mutations, mouse movements, scrolls and input. It takes a fresh snapshot every 30 seconds while the page changes, so there is always one to replay from.

The recording is kept on the user's device, per tab, for about the last two minutes. When an error fires (or a rage or dead click, or a failed request), the SDK uploads the last 60 seconds right away, starting from the snapshot just before them, so a recording is 60 to 90 seconds long. Ten seconds later it replaces that upload with one that also covers what happened after the error. If the tab closes in between, the first upload stays. Each recording is compressed (zlib) and linked to the error by its event UUID; open the error in the dashboard and press play in its Session replay section.

One upload per 10 seconds at most: an error within 10 seconds of the previous upload does not get its own recording, since that one already covers it.

Playback#

A replay is not a video file. When you press play, the dashboard downloads the recorded events and rebuilds the page in your browser with rrweb-player, inside a sandboxed frame where none of the recorded page's scripts run. You get a timeline, 1x to 8x speed, and skipping of idle stretches. The engineer app plays replays the same way, in an in-app browser view.

Fonts and images load from your site at playback time. If your site does not allow cross-origin loads of its fonts, the replay shows the same layout in fallback fonts.

Storage and bandwidth#

A replay of a typical page is tens of kilobytes compressed, and that is all the dashboard downloads to play it. Replays are uploaded only when an error fires, so on healthy sessions there's no replay traffic at all.

What is recorded#

rrweb records the DOM, so a replay shows your page as the user saw it. The defaults:

• Every <input> value is masked, password fields included: typed characters show as *.
• Page text is recorded as it is. Names, emails or amounts rendered as text appear in the replay unless you mask or block them (below).
• Cross-origin iframes are not recorded; same-origin iframes are.
• Web fonts and images are recorded as references, not embedded, so they load from your site at playback time.

Masking text#

Add data-rl-mask to an element to replace the text inside it with * while keeping its layout:

<p data-rl-mask>{user.email}</p>
<td data-rl-mask>{invoice.amount}</td>

Leaving elements out entirely#

For elements that should not be recorded at all (PII tables, billing details, internal IDs), use data-rl-block. Nothing inside is recorded; the replay shows an empty box of the same size:

<div data-rl-block>
  <h2>{user.name}</h2>
  <p>{user.email}</p>
  <p>{user.phone}</p>
</div>

Earlier versions of these docs named the attributes data-rr-block and data-rr-mask, which the SDK did not recognize. From SDK 1.5.1 both spellings work; on older versions only data-rl-* does.

Disabling replay#

If you don't want session replay at all (regulatory, performance, philosophical reasons), turn it off:

init({
  publicKey: 'pk_live_rl_...',
  captureReplay: false,
});

Performance impact#

The main cost is the full snapshot, which serializes the whole DOM, so it grows with the size of the page. It runs at start, every 30 seconds while the page changes, and when a hidden tab becomes visible again. In between, only changes are recorded, and nothing is recorded while the tab is hidden. On very DOM-heavy pages (large data grids), measure before enabling replay in production, or turn it off for those pages.