Debug Datadog RUM in Chrome DevTools

What Datadog traffic looks like

Datadog RUM batches browser telemetry (views, actions, resources, errors) into POSTs to region-specific intake hosts.

Endpoint pattern

rum.browser-intake-datadoghq.com for US-hosted orgs, rum.browser-intake-datadoghq.eu for EU ones, on an /api/v2/rum path; sites also running Datadog Browser Logs send similar batches to a sibling logs intake

Transport

POST with a newline-delimited JSON body: one RUM event per line

Key parameters

dd-api-key the public client token · ddsource=browser · ddtags carrying sdk_version, env, service, and version

Payload

Each line is typed by an event.type field: view (page/route views), action (auto-captured clicks or custom actions), resource (network timings), error, long_task. Each line also carries application.id, session.id, and the view URL

Cookies

First-party _dd_s encodes the session ID and the sampling decision

Two lines of a RUM batch, as Event Watcher captures it:

{ "type": "view", "application": { "id": "f0e1d2…" }, "session": { "id": "a9b8c7…" }, "view": { "url": "https://example.dk/checkout" } }
{ "type": "action", "action": { "type": "click", "target": { "name": "Add to cart" } }, "session": { "id": "a9b8c7…" } }

Debugging Datadog with Event Watcher

• Matches both the US and EU RUM intake hosts, names the traffic Datadog RUM, and files it under the monitoring category, keeping observability batches visually distinct from marketing tags.
• No dedicated parser: the parsed query parameters give you the client token, service, and env at a glance, and the NDJSON body lists the individual RUM events in the batch.
• The Cookies section shows _dd_s being sent.
• Script Tree shows whether the RUM SDK was bundled with the app or added through a tag manager.

Datadog and consent

Event Watcher checks Datadog against functional consent: it is performance and error observability, not marketing, and sets no cross-site advertising identifiers.

It still belongs in every serious tracking audit: it ships a session ID and full page URLs, and regulators do not exempt a tool just because its vendor calls it monitoring.

The RUM SDK has a built-in tracking-consent mechanism that buffers telemetry until granted. Batches with a pre-consent badge mean the SDK was initialized without that gate.

Whether pre-consent RUM is acceptable is a policy call; the extension gives you the timing evidence.

Common debugging scenarios

• RUM data missing for a subset of users. Sampling, almost always. Check _dd_s in the Cookies section and the configured sample rate rather than hunting for a blocking bug.
• Events attributed to the wrong service or environment. Read ddtags on the intake request; a copy-pasted init config with env:staging in production is common and visible in one glance.
• Intake fires before consent. Filter to Datadog and check consent badges. Pre-consent batches mean the SDK init is not wired to the CMP despite the site's policy saying it is.
• US vs EU intake. Verify which intake host actually receives data; an EU org sending to the .com intake is a data-residency finding.
• Is Datadog inflating "tracker" counts? In an audit, group by Tool and present monitoring traffic separately from marketing pixels. The category badge backs up that split.