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
Section titled “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
Section titled “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
Section titled “How it works”Replay is built on rrweb. The recorder:
- Snapshots the initial DOM.
- Records every mutation (additions, deletions, attribute changes).
- Records every input event (clicks, scrolls, typing).
- Records network requests (visually — you see the loading state).
- Batches and ships these as segments to
https://replay.siteqwality.com.
Playback in the dashboard:
- Replays the initial DOM.
- Applies each mutation in real time.
- Renders mouse cursor, click highlights, typing.
- Lets you scrub the timeline, jump to errors, slow down.
Activation
Section titled “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.
For sessions where you want replay from the very beginning, use the error filter with capture_replay: true — the SDK starts recording on the first error, but the rrweb library was already buffering, so playback typically includes the few seconds before the error.
Privacy
Section titled “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.
Per-element overrides:
<!-- Force masking on a specific element --><div class="rr-mask">Sensitive content</div>
<!-- Force unmasking --><div class="rr-unmask">Always-visible content</div>
<!-- Block from recording entirely --><div class="rr-block">Don't record this at all</div>The rr-mask / rr-unmask / rr-block class names are inherited from rrweb conventions.
Pricing
Section titled “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
Section titled “Limits”- Segment size: ~1MB per segment. Larger sessions are split into multiple segments.
- Retention: paid plans 30 days by default; configurable.
- Replay can be 10–100× the cost of plain RUM depending on session length and DOM complexity. Filter aggressively.