Session replay built on open-source rrweb, wired into error tracking
See every click, input and route change before the crash — opened from the error it explains, stored on your own infrastructure if you want it there.
rrweb records the DOM, not the screen
rrweb is an open-source library, MIT licensed, that takes a different approach to session replay than screen recording. It serialises the initial DOM once, then records a stream of mutations: nodes added and removed, attributes changed, inputs typed, scroll positions moved, the mouse path between them. Playback rebuilds the page in a sandboxed iframe and replays that stream against it.
The consequences are practical. An rrweb session replay is text, so it compresses hard and stays small next to video of the same session — ours are gzipped in the browser before upload. Seeking is cheap because the player fast-forwards mutations rather than decoding frames. Text stays selectable, the DOM stays inspectable, and the recording is data you can reason about instead of pixels you have to watch.
Because rrweb is open source, the recorder is not a black box we ask you to trust. Read it.
Replay and error in the same place
Most session replay tools are standalone products, usually sold for funnel and product analytics. That leaves you correlating by hand: an issue in one system, a session list in another, timestamps and a user id to join them.
Remetry stores replays against sessions and surfaces them from the issue detail screen. "Open replay" on an error plays the session that threw it. The default on-error mode keeps a ring buffer in memory and flushes it the moment the first error fires, so the seconds leading up to the crash are always there without recording every session that ended fine. The recorder is a lazily-loaded chunk, kept out of your initial bundle.
That is what session replay for React looks like when it ships inside the error tracker instead of beside it. The rest of the platform sits on the same events: symbolicated React stack traces, per-endpoint API latency, and a per-deploy regression verdict. One pipeline, not four vendors.
Self-hosted session replay, or ours
Replay is the most sensitive data the platform holds. Deciding whose disk it lands on is the first decision, not an afterthought.
Your own buckets
Replay chunks land in your MinIO, metadata in your Postgres, events in your ClickHouse. Nothing crosses your network boundary.
Remetry Cloud
Same code, our infrastructure. Sign up, create a project, add the replay plugin to your SDK init.
- Storage, retention and upgrades handled
- Project-scoped API keys and team access
- Move to self-hosted later without changing the SDK
Defaults that assume the worst
Inputs are masked by default — you opt into recording what people type, never out of it. [data-remetry-block] drops an element from the recording entirely; [data-remetry-mask] keeps the layout and hides the text. sampleRate decides how many sessions record at all, and at 0 the rrweb chunk is never even fetched.
Retention is enforced server-side by a sweeper that deletes expired sessions and their chunks on a schedule you configure. There is an erasure path too: one end-user or a whole project can be deleted across every store — events, metadata, replay blobs, source maps — and the deletion is audited.
Self-hosting is the strongest version of all of this. No third party holds the recording of your checkout flow, because there is no third party.
Precisely which part is open source
rrweb is open source: MIT, permissive, no strings. It is the recorder and the player, and it would keep working without us.
Remetry is not open source. It is source-available under the Functional Source License 1.1: read it, modify it, self-host it, run it commercially inside your company — but do not resell it as a competing service. Two years after a version ships, that version converts to Apache 2.0, which is a real OSI license granted up front.
We spell this out because "open source session replay" gets used loosely, and a license you find out about later is a bad surprise. The recording layer is open source. The platform around it is source-available with a dated grant.
Questions we get about replay
Is rrweb open source?
Yes. rrweb is open source under the MIT license and is the library Remetry uses to record and replay sessions. Remetry itself is source-available under FSL-1.1 with an Apache 2.0 future grant, which is a different thing and we do not call it open source.
Is a replay a video recording of the screen?
No. rrweb serialises the initial DOM and then a stream of mutations, input and scroll events. Playback rebuilds the page in an iframe and replays those events, so a replay is small, text-based, seekable, and readable as data rather than pixels.
How do I keep private data out of a replay?
Inputs are masked by default. Add [data-remetry-block] to remove an element from the recording entirely, or [data-remetry-mask] to keep its shape and hide its text. sampleRate controls how many sessions record at all, and at 0 the rrweb chunk never loads. Self-hosting keeps every chunk in your own MinIO bucket.
Can I use session replay without error tracking?
That is not the point of it. Replays are stored against sessions and surfaced from the issue they belong to, and the default on-error mode only flushes the ring buffer when an error fires. Replay here is evidence for a bug, not a product-analytics tool.
Watch the bug instead of guessing at it
Add the replay plugin to your SDK init, on our cloud or your own stack.