Most teams that have session replay bought it from a different vendor than the one holding their traces. That is not an accident of procurement. It is a lineage. Session replay came out of product analytics and UX research, where the question was how people use a page, and it was built as its own product with its own SDK, its own storage, and its own UI. Observability came from somewhere else entirely and never had a reason to speak that language.
So you end up owning two systems that each saw half of what happened, and the best either can offer is a link to the other.
That arrangement is fine right up until the moment it matters.
The handoff is where the investigation dies
Consider what you actually do with a replay. You watch a user fail at something. You get to the moment where the page stopped responding, and the next question is immediate and obvious: what was the backend doing right then?
Now you leave. You copy a timestamp, switch tools, and try to find the trace that corresponds to a moment you can no longer see. Maybe there is a session ID you can paste somewhere. Maybe the clocks agree. You are performing a join by hand, under time pressure, between two systems that were never introduced.
Most of the time you give up and go back to guessing. Not because the data is missing, but because the cost of connecting it exceeds the value of the answer. The replay told you what happened. It cannot tell you why, and the thing that can is one tool away.
Two halves of one incident, filed separately.
Correlation should fall out of the data, not sit on top of it
The usual fix is integration. Vendor A ships a connector to Vendor B, a session ID gets propagated, a deep link appears in a side panel. It works in the demo.
The trouble with correlation as a feature is that features have edges. The link exists for the paths someone implemented, and anywhere outside those paths you are back to timestamps. It breaks when a schema changes on either side. It is maintained by a team with no incentive to maintain it well, because the integration is a checkbox for them and a workflow for you.
Correlation is worth more when nobody has to build it. When the two things were never separate, there is no join to get wrong.
So we didn't make it separate
In Dash0, a session replay is not a separate artifact with a pointer to telemetry. It is telemetry.
The Web SDK captures the DOM with rrweb and transmits the recording as browser.session_recording log records. The same ingestion endpoint as everything else, the same auth token, the same dataset, the same region, the same retention machinery. Nothing about the transport is special.
The part that does the work is one property of the data model: every record of a recording shares a trace ID that embeds the session ID.
That sentence is the entire design. Because the session ID lives inside the trace ID, any span or log belonging to that session already knows how to reach the replay, and the replay already knows how to reach them. There is no lookup table, no connector, and no integration to maintain. The relationship is structural.
The practical consequence is that you can start from either end and the route to the other is already in the data. Pause a replay on a failed request and the backend trace it started is one click away. Open a trace that began in the browser and it leads back to the session, and from there to the recording. The thing you were debugging as a 500 becomes a person waiting on a spinner, and the spinner becomes a database call that took eleven seconds.
Same investigation. No handoff.
Collected together by default
A session and the backend traces it produced are both collected by default, and the trace ID is what ties them together. The share of sessions you record is configurable, and that decision is deterministic per session ID using the same hash as session sampling, so recordings are a subset of the sessions the browser already reports rather than an independent draw.
The exception is whatever you have configured downstream for backend spans. Tail-sampling rules and spam filters in SignalControl make their own decisions about which spans to keep, and those decisions do not take recorded sessions into account. If following a replay into a trace is a workflow you rely on, it is worth checking those rules.
Masking is a capture-time problem
Recording what a user saw means recording what a user typed. That makes privacy a property of how a recording is made rather than something applied to it afterwards.
So masking runs in the browser, before a recording leaves the page. The value of every visible input, textarea and select is masked by default, which means the common case is handled the moment you start recording, with nothing to configure.
From there you can go as far as your pages require. Mask the text of specific elements, mask the whole page, leave elements out of the recording entirely, or pass your own function to scrub values such as email addresses. Sites differ in where sensitive content sits, so treat the defaults as a floor and use the controls to raise it where your pages need it. We are extending what the SDK masks out of the box in upcoming releases.
Recording is also opt-in twice over. The recorder is a separate bundle, so sites that do not record do not carry the bytes, and nothing is captured until you load it. You decide when it starts, which is where consent flows belong.
The limits are part of the honest version
Replays load assets such as images and fonts from your site. If those sit behind a login or have changed since the session, the replay can look unstyled or differ from what the user saw. Canvas content does not appear unless you turn canvas recording on, which makes recordings larger. Content in iframes served from another origin, such as payment forms, is not recorded. Iframes from your own origin are.
Recordings are kept for 30 days, in the same region as the rest of your telemetry.
The point
Session replay is not a new category of data. It is a very high resolution record of one session, and sessions are already something your observability system understands.
Treating it as telemetry rather than as a neighboring product removes the one step where investigations usually stop: the handoff. Everything else here, the sampling that lines up by default, the single retention story, the fact that there is no integration to break, falls out of that choice rather than being built on top of it.
Watch a Session Replay covers what a replay shows you. Web SDK Setup covers turning it on.