Debug RudderStack in Chrome DevTools

What RudderStack traffic looks like

RudderStack deliberately implements the Segment spec, so its payloads read almost identically: the difference is in the hosts.

Endpoint pattern

SDK from cdn.rudderlabs.com (for example /v1.1/rudder-analytics.min.js), source configuration from api.rudderstack.com/sourceConfig, events to a per-workspace data plane: dataplane.rudderstack.com on managed setups, or a custom first-party domain on self-hosted ones

Transport

JSON POSTs to the familiar paths (/v1/track, /v1/page, /v1/identify, /v1/group, /v1/alias, and /v1/batch) with the write key sent as Basic auth

Payload

Segment-spec body: type · event · properties · userId · anonymousId · a context object (library, page, campaign, locale) · messageId · timestamps, the same fields you would inspect on a Segment call

First-party variants

Because the data plane is often self-hosted, the giveaway on an unfamiliar domain is the path structure and the Segment-spec body, not the hostname

A typical /v1/track body, as Event Watcher captures it:

{
  "type": "track",
  "event": "Order Completed",
  "userId": "u-4821",
  "anonymousId": "9d2c1e…",
  "properties": { "total": 499, "currency": "DKK" },
  "context": { "library": { "name": "rudder-analytics-js" }, "locale": "da-DK" },
  "messageId": "m-7f31…"
}

Debugging RudderStack with Event Watcher

• Parsed with the shared Segment-spec parser: track calls show their event name in the stream, identify shows the userId, page shows the page name, and batch requests unpack into individual events.
• The detail view separates properties, traits, IDs (userId, anonymousId, write key), and context, plus any consent data in the payload.
• Migrating from Segment (a common reason RudderStack shows up at all)? Grouped view by Tool compares both pipelines' event names and counts side by side on the same page.
• The managed dataplane.rudderstack.com host is detected out of the box; fully custom first-party data-plane domains may not match the URL patterns.

RudderStack and consent

Event Watcher checks RudderStack against the analytics consent category. Like Segment, the SDK auto-fires a page call on load: an ungated snippet produces a pre-consent /v1/page hit at render, visible in the stream and totaled by the violations counter.

Consent-manager integrations (OneTrust, Ketch, a custom provider API) suppress specific device-mode destinations rather than the SDK itself. A compliant setup can still legitimately send to the data plane, so check what actually left the browser.

Common debugging scenarios

• Events on an unknown first-party domain. Inspect the request body: a Segment-spec JSON with anonymousId and context.library naming the Rudder SDK identifies a self-hosted data plane even when the hostname matches nothing.
• Segment-to-RudderStack migration drift. Run both, group by Event Name, and diff: renamed or dropped events surface immediately.
• Automatic page call fires before consent. Check the consent state on the first /v1/page event; if it is pre-consent, the snippet loads unconditionally.
• A device-mode destination still fires despite denied consent. Look for the destination's own native requests in the stream. The consent-manager integration only suppresses destinations it knows about.
• Duplicate track calls. Use script attribution to see whether both the site's code and a tag manager are wiring the same event.