Debug LogRocket in Chrome DevTools

What LogRocket traffic looks like

LogRocket multiplexes replay, console, network metadata, errors, and state actions into compressed batched uploads, not per-event readable hits.

Endpoint pattern

SDK from cdn.logrocket.io; session data as a steady rhythm of ingestion POSTs to r.logrocket.io for as long as the session runs

Transport

Batched, compressed POST uploads. LogRocket records more than DOM replay: console output, network request/response metadata, JavaScript errors, and Redux or state-management actions can all be captured, multiplexed into the same uploads; identify calls (LogRocket.identify(uid, traits)) and custom events travel inside those batches too

Key parameters

App ID in org-slug/app-slug form (the routing key for everything that follows) plus session identifiers in the request; the readable surface is the app ID, session IDs, upload cadence, and the timing of the first upload relative to consent

Debugging LogRocket with Event Watcher

• No dedicated parser: requests are identified by hostname, badged with the LogRocket name and Session Replay category, and displayed with parsed query and body parameters plus cookies.
• That covers the practical checks: the SDK loading from cdn.logrocket.io on the right pages, ingestion POSTs to r.logrocket.io confirming an active recording, and the app slug confirming which LogRocket project receives the session.
• One LogRocket-specific angle: the SDK instruments fetch/XHR to log network activity into the replay, so it is a frequent suspect in odd request behavior. The Script Tree view separates what LogRocket itself loaded from the traffic it merely observes.

LogRocket and consent

Event Watcher checks LogRocket against the analytics consent category.

LogRocket typically arrives via engineering (bug reproduction, frontend monitoring) rather than the marketing tag stack, so it often bypasses CMP wiring entirely; nobody in the consent workflow knew it existed.

The wire-level check is simple: ingestion POSTs to r.logrocket.io before the CMP resolves are marked pre-consent and counted as violations.

Since LogRocket can capture console content and network payloads, pre-consent or unsanitized capture is worth escalating beyond the usual analytics-cookie conversation.

Common debugging scenarios

• Sessions not appearing in LogRocket. Confirm the SDK loads and ingestion POSTs follow. A script load with no uploads points at init never running or a conditional wrapping it.
• Recording into the wrong project. Read the org/app slug from the requests. Staging and production apps get swapped in copy-pasted init code.
• Recorder found during a tracking audit. LogRocket frequently surfaces as an unexpected platform on sites where the marketing team never listed it. The Script Tree view shows who loaded it.
• Capture before consent. Check the consent state on the first r.logrocket.io upload of the session.
• Suspected recorder overhead. Watch the ingestion cadence and payload sizes on a heavy page. Constant large uploads explain performance complaints better than guesswork.