Watch the session
the ticket is about.
Datadog Session Replay records what the user saw and did, frame by frame, with the RUM events and the backend trace underneath. We implement it with masking that holds, sample it for the sessions that matter, and run it every month so the recording is there when the ticket arrives.
Quick facts
Related
- Real User Monitoring, the sessions the replays sit on
- Error Tracking, the issue the replay reproduces
- Product Analytics, the funnel the replay explains
The reproduction step, done for you
The ticket says the form would not submit. The logs show no request arrived. Somewhere between the user and the server, a button did nothing, and the only witness has closed the tab. Session Replay is that witness, kept.
What the user saw, in order. Each click, scroll and page change, played back as the page rendered for that user on that device. The error that only happens on an iPad in landscape is now a recording, not a rumour.
The developer tools alongside. Console errors, network requests and performance timings line up with the moment in the replay. You see the spinner start, and the request that never returned, at the same timestamp.
The trace underneath. With RUM joined to APM, the request in the replay opens the backend trace that served it. The frontend fault and the backend cause are one click apart instead of two teams apart.
Masked before it leaves the browser. Text, inputs and images are replaced in the browser by default, and sensitive fields are always masked. What the regulator cannot see, Datadog never received.
A privacy level set for the demo, and a replay rate that records the bounce and misses the bug
How it bills. Session Replay is a per-session meter on top of RUM, and Datadog lists it as an add-on to RUM Investigate. A session kept with its recording is billed on the replay meter as well as the RUM meter, and a replay used in both RUM and Product Analytics is billed once. The replay sample rate in the SDK is applied on top of the RUM sample rate, so it decides which of the collected sessions are recorded. Replays are kept for 30 days by default, the same as a retained RUM session, and individual replays can be kept for 15 months with Extended Retention. Datadog publishes the rates. We publish nothing here, because the price is not the problem. Which sessions get recorded is.
The configuration traps. The default privacy level masks everything, which is safe and makes the replay a wireframe. The first instinct is to switch the whole site to allow so the demo looks good. That setting is then live on a page that renders a customer's address. Masking is applied in the browser and cannot be undone, which is good, and cannot be added after the fact, which is the problem. On the other side, a replay rate that records a flat share of all sessions fills the quota with one-page visits and records none of the session where the error happened. Neither of these raises an alert. One shows up in a data protection review and the other when a replay is needed and is not there.
Field noteThe most common gap we see is the privacy level set once, globally, during setup. It is either mask everywhere, so the replays show nothing useful, or allow everywhere, so a page that was added later renders personal data nobody reviewed. The per-element overrides sit unused, and the first time anyone looks at them is during a data protection review.
Field noteReplay sampling is a flat percentage of all sessions. The sessions worth watching are the ones that hit an error, and those are not sampled any differently from the ones that bounced. The recording the ticket needs was in the share that was not recorded.
Field noteThe pattern we keep finding is a replay with no trace underneath. RUM was never joined to APM, so the replay shows a spinner, the network tab shows a request, and the backend side of that request is in a different tool with a different clock.
Field noteA frontend framework upgrade changes how inputs are rendered. The masking rules written against the old markup no longer match, and a field that was masked last quarter is visible this quarter. Nothing failed. The release notes did not mention it, because it was not a feature.
Masking first. Sampling rules second. Then the join to the trace.
Session Replay rides on RUM, so it is implemented with RUM. If neither is on, LaunchPad runs both as a managed project, and the Digital Experience Accelerator covers replay for error sessions in its four weeks. If RUM already runs, a Datadog HealthScan reports replay volumes and the privacy configuration before we change anything.
- Walk the pages with the data owner. Which screens render personal data, which render card or health data, and which an engineer needs to see unmasked to fix anything. The answer is a list, per application.
- Keep mask as the default and override per element. The privacy level stays at mask. Elements an engineer needs are allowed by attribute, one at a time, with the reason recorded next to each override.
- Set the replay rate and the trigger rules. A low baseline share of sessions, plus recording for sessions that hit an error, a rage click or a flow that matters. The replay meter follows the bugs, not the bounces.
- Join the replay to the trace. The backend hosts go on the RUM tracing list. We confirm by opening a replay, picking a request, and reading the span behind it.
- Build the playlists and the handoffs. A saved view for the support team and a playlist per recurring issue. Each Error Tracking issue links to the replays that show it.
- Hand over, in writing. The masking decisions and why, the sampling rules, the retention, and which hosts are traced. Plus a note for the privacy team that says exactly what is recorded and what is not.
Access is admin on the Datadog organisation plus a pull request into the frontend repositories, or a working session with whoever owns them. We do not need production shell access to implement Session Replay, and we do not ask for it.
The masking was right on the day. The frontend has shipped forty times since.
A new form appears. A component library changes its markup. A campaign doubles the sessions on a page and the replay quota goes with them. Managed Observability is the monthly service that keeps Session Replay recording what it should and nothing it should not.
Every month, we review the meter. Recorded sessions per application against the replay rate and the trigger rules, alongside the RUM session count they sit on. Anything that moved gets a reason or a fix.
Coverage follows the releases. New applications and new flows are added to the trigger rules, so the first replay of a new checkout exists before the first ticket about it.
The masking is kept honest. After frontend releases we open replays of the pages that render personal data and check the mask still holds. A framework upgrade is a privacy review, whether or not it was labelled one.
The incident is ours to take. When a replay shows a production fault, Critical Support takes it from there, 24x7, with the recording as the first piece of evidence rather than the last.
We operate the stack. You own the product.
An implementation partner switches recording on and hands it over. A managed partner is still there when a component upgrade unmasks a field in March. We are the second kind. The privacy decisions, the sampling rules and the playlists stay in your Datadog organisation, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Session Replay, answered plainly
How is Datadog Session Replay billed?
Session Replay is a per-session meter on top of RUM, and Datadog lists it as an add-on to RUM Investigate. A session kept with its recording is billed on the replay meter as well as the RUM meter, and a replay used in both RUM and Product Analytics is billed once. The replay sample rate in the SDK decides which sessions get a recording, and it is applied on top of the RUM session sample rate. Replays are kept for 30 days by default, the same as a retained RUM session, and individual replays can be kept for 15 months with Extended Retention. We do not publish prices. The replay sample rate is what we tune.
Does Session Replay record passwords and card numbers?
No. Password, email and telephone inputs, and fields marked with sensitive autocomplete types, are always masked whatever the configuration. Beyond that, the default privacy level masks all text, inputs and images, so the replay is a wireframe of the page. We relax that per element, never per site, so the parts of the page an engineer needs to see are visible and the parts a regulator would ask about are not. Masking happens in the browser before anything is sent, and it cannot be reversed later.
Do we need to record every session?
No, and most estates should not. The replay sample rate is a separate control from RUM sampling, so you can collect every RUM session and record a small share of them. The usual pattern is a low baseline rate plus a rule that records the sessions that hit an error, a rage click or a flow that matters. That gives you the recording when the ticket arrives without paying to store a recording of every bounce.
Can we see the backend trace from inside a replay?
Yes, if RUM is joined to APM. The replay sits on top of the RUM session, and each network request in that session carries a trace header when the backend host is on the SDK tracing list. From the moment in the replay where the spinner stops, you open the request, then the trace, then the span that took the time. If the tracing list is empty, the replay shows the spinner and nothing else.
What does Critical Cloud do with Session Replay every month?
Managed Observability runs it every month. We review recorded sessions per application against the replay sample rate and the rules that trigger a recording. We check the masking still holds after frontend releases, add new applications and flows to the recording rules, and report what changed. When a replay points at a production fault, Critical Support takes the incident, 24x7.
- Datadog products: every product, and how we implement and run each one
- Real User Monitoring: the sessions underneath every replay
- Sensitive Data Scanner: personal data found in logs and traces, the other half of the privacy review
- Digital Experience Accelerator: RUM, replay and Synthetics in four weeks
The recording is there when the ticket arrives. The personal data is not.
Tell us which pages render personal data and which flows break most. We will tell you what Session Replay is recording today, what it should be, and what it costs to get there.