See the page load
the way the customer saw it.
Datadog RUM records every real session in the browser and the mobile app: page loads, Core Web Vitals, errors and the path the user took to the complaint. We implement it, set the sampling so the bill holds, and run it every month so the frontend data still matches the product.
Quick facts
Related
- Session Replay, the session, replayed, with the trace underneath
- Synthetic Monitoring, the same pages tested before anyone is on them
- Error Tracking, frontend errors grouped into issues
The complaint, with the evidence attached
The ticket says the checkout hangs. The backend says every request returned in under a second. Both are true. The hang is a third-party script on a slow phone on a train, and only the browser knows that. RUM is the browser telling you.
Every session, as it happened. Views, clicks, network requests, errors and crashes, in order, for each real user. The slow page is a page you can name, on a device you can name, in a release you can name.
Core Web Vitals from the field, not the lab. Largest Contentful Paint, Interaction to Next Paint and layout shift per page, per browser, per country, per version. The number Google scores you on, measured on your users.
The frontend joined to the backend. With the backend hosts listed in the SDK and unified service tags in place, the slow request in the session opens the APM trace that served it. The argument about whose fault it is gets shorter.
Monitors on what users felt. Error rate per view, vitals per page, crash-free sessions per mobile release. Alerts that fire because a real person had a bad time, not because a server was warm.
A sample rate nobody set, a version nobody bumps, and a tracing list nobody filled in
How it bills. RUM is billed per session. A session is one continuous period of activity, ending after fifteen minutes of inactivity and capped at four hours. Datadog sells it as two meters: RUM Measure, counted on every session the SDK collects, and RUM Investigate, counted only on the sessions the retention filters keep for 30 days. RUM Managed Archive is an add-on to Measure that stores every collected session for one, three or six months. Session Replay is a separate per-session add-on to RUM Investigate, and Product Analytics is another per-session meter on the same data. A mobile app with an instrumented webview bills one mobile session. The sample rate in the SDK decides how many sessions are collected and the retention filters decide how many are kept, so those are the two controls that matter. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The sample rate and the retention filters are.
The configuration traps. The browser SDK collects every session unless told otherwise. That is right for a trial and wrong for a marketing site with a high bounce rate, where most sessions are one page and a departure. Service and version default to whatever was typed when the application was created. Consent defaults to granted. The list of backend hosts that get trace headers defaults to empty. None of these produce an error. All of them produce either a bill or a blind spot, and sometimes both.
Field noteThe most common gap we see is one sampling decision for the whole estate. The marketing site and the logged-in app share a sample rate chosen for one of them, and no retention filter separates the sessions with a basket in them from the ones that bounced. The sessions worth having are a small fraction of the sessions being paid for.
Field noteThe version tag is set once, at setup, and the build pipeline never updates it. Every release reports as the same version. When a deploy breaks a page, RUM cannot say which deploy, and the regression is found by reading the git log instead.
Field noteThe pattern we keep finding is RUM and APM running side by side and never joined. The SDK has no backend hosts listed, so no request carries a trace header. The slow action in the session has nothing underneath it, and the frontend and backend teams each have a dashboard that proves it was the other one.
Field noteThe consent wiring is built for one cookie banner. The banner is replaced during a redesign, the SDK still starts with the old default, and a whole region of users either stops reporting or starts reporting before they were asked. Neither is noticed until someone compares the session counts by country.
One application per product. A sample rate per application. A version per release.
If RUM is not on yet, LaunchPad runs the rollout as a managed project, and the Digital Experience Accelerator adds Synthetics and the dashboards in the same four weeks. If RUM is already on, a Datadog HealthScan reports session volumes, tagging and the trace link before we change anything. Either way, the sequence is the same.
- Agree the application inventory. Which web apps and mobile apps exist, which flows in each earn money or keep a promise, and which team owns the frontend of each. Each gets its own RUM application and its own sample rate.
- Wire service, env and version into the build. The version comes from the release pipeline, not from a text box. The service name matches the one the backend uses, so the two halves of the trace agree.
- Load the SDK once, asynchronously, with consent handled. The tracking consent state follows the cookie banner, in both directions. We check the SDK is not already there under another name before we add it.
- List the backend hosts for tracing. Every API the frontend calls that we also trace with APM goes on the list. We confirm the join by opening a session and following a request to its span.
- Set the sample rates and the monitors. A rate per application, chosen from a fortnight of real traffic and the flows that matter. Monitors on vitals per page, error rate per view and crash-free sessions per mobile release.
- Hand over, in writing. Which applications exist and which sample rate each runs. How the version tag is set, which hosts are traced, and the session volumes on the day we finished.
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 RUM, and we do not ask for it.
The frontend ships every week. RUM has to keep up with it.
A new single-page app launches without the SDK. A redesign changes every view name. A traffic campaign triples the sessions on a page nobody sampled for. Managed Observability is the monthly service that keeps RUM matching the product it watches.
Every month, we review the meter. Sessions per application against the sample rate, with the Session Replay and Product Analytics meters alongside. Anything that moved gets a reason or a fix.
Coverage follows the releases. A new app, a new mobile platform or a new flow is found in the application review and instrumented before it is the thing the support queue is about.
The version tag stays honest. We check that each release shows up in RUM as a new version. When the pipeline stops setting it, we find out from the data, not from the next incident.
The incident is ours to take. Under Critical Support our engineers answer the alert the session raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner drops the SDK in and hands it over. A managed partner is still there when the sample rate is wrong in March and the version tag stopped updating in June. We are the second kind. The RUM applications, the dashboards and the decisions 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 RUM, answered plainly
How is Datadog RUM billed?
Datadog RUM is billed per session. A session is one continuous period of activity in the browser or the app, which ends after fifteen minutes of inactivity and is capped at four hours. Datadog sells RUM as two meters: RUM Measure, counted on every session the SDK collects, and RUM Investigate, counted only on the sessions the retention filters keep for 30 days. RUM Managed Archive is an add-on to Measure that stores every collected session for one, three or six months. Session Replay is a separate per-session add-on to RUM Investigate, and Product Analytics is another per-session meter on the same data. A mobile app with an instrumented webview bills one mobile session, not two. The session sample rate in the SDK decides how many sessions are collected and the retention filters decide how many are kept, so those two controls set the bill. We do not publish prices. The sample rate and the retention filters are what we tune.
Does Datadog RUM slow the page down?
Not in a way a user notices, if it is loaded properly. The browser SDK is a small script that batches events and sends them in the background. The usual mistake is loading it synchronously in the head, or loading it twice because two teams added it. We load it asynchronously, once, with the version pinned, and we check the page weight before and after in the same Core Web Vitals dashboard RUM produces.
How does RUM connect to our Datadog APM traces?
The SDK adds trace headers to the requests your frontend makes to the backend hosts you list in its configuration. If those hosts are not listed, there is no link, and the slow request in the session has no trace behind it. With the list set and unified service tagging in place on the backend, one click moves from the user action to the backend span that took the time.
What is the difference between RUM and Synthetic Monitoring?
RUM records what real users experienced. Synthetic Monitoring runs scripted tests on a schedule from locations you choose, whether or not anyone is using the site. RUM tells you a checkout was slow for users in Dublin on Safari. Synthetics tells you the checkout is broken at 3am before any user finds out. Most estates need both, and they share the same dashboards.
What does Critical Cloud do with RUM every month?
Managed Observability runs it every month. We review session volumes per application against the sample rates and check that every release carries a new version tag. We add new pages and apps to the coverage, retire frontend monitors that no longer fire for a real reason, and report what changed. Under Critical Support our engineers also take the incident the session points to, 24x7.
- Datadog products: every product, and how we implement and run each one
- Session Replay: the session the ticket is about, watched back
- Product Analytics: funnels and retention on the same sessions
- Digital Experience Accelerator: RUM, Synthetics and the dashboards in four weeks
Sessions that explain the complaint. A bill that holds.
Tell us which flows earn the money. We will tell you what RUM is seeing today, what it should be seeing, and what it costs to get there.