The SDK keeps a rolling window of the DOM in memory. When a report is filed that window is frozen and attached; the rest is discarded. Nothing is uploaded unless someone files a report.
Turning it on
Replay is server-gated — enable it for the app in the dashboard, and the SDK
picks it up from GET /api/config on the next start.
Locally you can only turn it off:
<TraceItXProvider config={{ apiKey: 'txx_live_…', sessionReplay: { disabled: true } }}>samplingRate on the server is the fraction of sessions that buffer at all. At
0.1, nine in ten sessions never allocate the buffer — which is how you keep
the memory cost off most users while still getting replays.
Format
Web replays are rrweb, attached with kind: "session-replay" and
format: "rrweb". A player dispatches on format rather than sniffing bytes;
the native SDKs emit traceitx-vtree-v1 instead, and both share the report’s
epoch-ms clock so replay frames align with
breadcrumbs.
Privacy
Elements marked sensitive are blocked in the recording — rrweb never serialises their subtree, so the content never enters the buffer, let alone the upload. See Sensitive content.
Text redaction rules are not applied to the replay
stream in the current release: the recorder captures text and input values as
rendered. A secret that appears on screen must be wrapped in <Sensitive>; a
redaction rule alone will not keep it out of the replay.
Cost
The buffer holds a serialised DOM diff stream, not video, so it is measured in
tens of kilobytes rather than megabytes. The practical limit is memory on
long-lived sessions; replayDurationSec on the server bounds the window.