Session Replay

Session Replay reconstructs a user’s session as a video: every page view, every DOM mutation, every click, every keystroke (with privacy controls). Use it for the “what did the user actually do?” debugging that no amount of metrics or logs can answer.

When to use replay

• A user reports a bug you can’t reproduce.
• You’re investigating an error and want to see the exact path that triggered it.
• You’re studying a confusing UX flow and want to watch real users navigate it.
• A customer asks “why was I charged twice?” You can replay the actual checkout.

When NOT to use replay

• For aggregate analytics. That’s RUM’s measurement layer.
• As your only data source. Replay is heavy and only captured for filter-matched sessions. The other observability pillars are still your high-level monitoring.

How it works

Replay is built on rrweb. The recorder:

1. Snapshots the initial DOM.
2. Records every mutation (additions, deletions, attribute changes).
3. Records every input event (clicks, scrolls, typing).
4. Records network requests (visually, so you see the loading state).
5. Batches and ships these as segments to https://replay.siteqwality.com.

Playback in the dashboard:

1. Replays the initial DOM.
2. Applies each mutation in real time.
3. Renders mouse cursor, click highlights, typing.
4. Lets you scrub the timeline, jump to errors, slow down.

Activation

Replay is off by default. It activates only for sessions matching a session filter with capture_replay: true.

Once activated for a session, replay records from the activation moment onward, not from session start. So an errored session might have replay starting halfway through, when the error fired.

Nothing is buffered before the trigger

There is no pre-trigger buffer. The rrweb library is lazy-loaded: the SDK only fetches it once a replay-enabled filter matches, so nothing is being recorded, or even downloaded, before that moment. Playback starts at the activation point and never includes the lead-up to it.

This page previously claimed that recording with an error filter included “the few seconds before the error”. It does not.

Privacy

Replay is a privacy-sensitive feature. Two SDK-level controls (set on the RUM application):

• mask_inputs: replace input values with *** in the recording. Critical for password fields, credit card forms.
• mask_text: replace user-visible text with ***. Use when displaying customer names, financial figures, etc.

Both are stored per RUM application, and both are shown as toggles on the application’s privacy settings in the dashboard. Check them there before you rely on either. The toggles reflect what is actually stored for your application, which is the only thing that governs what gets recorded. Do not assume a default.

Per-element overrides:

<!-- Mask the text of this element and everything nested inside it -->
<div class="rr-mask">Sensitive content</div>

<!-- Record this element as an empty placeholder; its subtree is not recorded -->
<div class="rr-block">Don't record this at all</div>

<!-- Do not record input events fired on THIS element. Put it on the input itself -->
<input class="rr-ignore" />

The rr-mask / rr-block / rr-ignore class names are rrweb’s own defaults. The SDK does not override them, which is why they work. They do not behave alike, and the differences matter more than the similarity:

Class	What it covers	Cascades to descendants
rr-mask	Text nodes only. Not input values, not attributes, not alt / title / placeholder.	Yes
rr-block	The whole subtree. The element itself is still recorded, as an empty box of the right width and height.	Yes
rr-ignore	Input events fired on the element carrying the class.	No

rr-ignore does not cascade, and does not cover the initial value

Two things about rr-ignore catch people out, and both come from how rrweb implements it.

It is checked with classList.contains on the element the event fired on, with no walk up the tree. <div class="rr-ignore"><input /></div> therefore protects nothing: the class has to go on the <input> itself.

Even placed correctly it only suppresses input events. The DOM serialiser never consults it, so a value already sitting in the field when recording starts is captured in the initial snapshot regardless. For a pre-filled field, use mask_inputs, or rr-block on its container.

rr-mask is the one to reach for when the concern is rendered text, and it is the only per-element control that cascades and masks rather than removes. If the concern is an input value, mask_inputs on the application is the control that covers it; rr-mask does not.

There is no per-element unmask

Masking is one-way. rr-mask adds masking to an element; nothing removes it. rrweb 2.0.0-alpha.4, the version this SDK pins, has no unmask option of any kind, so a rr-unmask class (or any other unmask attribute) does nothing and raises no error.

This page previously documented rr-unmask. It was never implemented. If you added it to an element expecting it to change behaviour, it did not.

Caution

mask_text is off by default, so all user-visible page text is recorded verbatim unless you turn mask_text on or add rr-mask yourself. Applying rr-mask to individual elements is the only per-element control available. For PCI/HIPAA-sensitive apps, audit replays before relying on them, and consider whether replay is appropriate at all.

Pricing

Replay is paid. Sessions with replay are billed per recorded session and per stored MB. Set conservative session filters. Do not “replay everyone.”

Limits

• Segment size: ~1MB per segment. Larger sessions are split into multiple segments.
• Retention: 30 days, fixed, on every plan. It is the same on the free tier and on every paid replay pack, and it is not configurable. Two independent mechanisms both enforce 30 days: a TTL on the rum_replay_segments index and a flat 30-day expiry rule on the S3 bucket holding the recordings. Buying a larger replay pack raises the number of sessions you can record, not how long they are kept.
• Replay can be 10–100× the cost of plain RUM depending on session length and DOM complexity. Filter aggressively.

See also

Quickstart Enable replay for error sessions in your RUM app.

Privacy considerations What rr-mask / rr-block actually do.

Session filters The activation mechanism.

RUM overview The parent pillar.