Debug PostHog in Chrome DevTools

What PostHog traffic looks like

PostHog's endpoint path tells you what a request is before you open it: events, queued batches, or feature-flag config.

Endpoint pattern

PostHog Cloud sends to us.i.posthog.com or eu.i.posthog.com (older setups use app.posthog.com or bare /e, /capture, /batch paths); /e and /capture carry events, /batch carries queued arrays, and /decide or /flags are config calls that return feature flags (frequent, but not tracking events). Session-recording ingest and the recorder/survey script bundles are split out to their own tools (below)

Transport

JSON or form-encoded data=<base64 JSON>, optionally gzip-compressed by the SDK

Key parameters

event the name: auto-instrumentation uses dollar-prefixed names ($pageview, $pageleave, $autocapture, $identify) · properties.distinct_id the identity key, plus $session_id and $window_id · properties.token the project API key (phc_…) · $elements on $autocapture: a chain describing the clicked DOM path, the reason autocapture payloads are an order of magnitude larger than custom events

First-party variants

Self-hosted and reverse-proxied deployments change the hostname entirely, which matters for detection (below)

A typical capture call, as Event Watcher shows it:

{
  "event": "$pageview",
  "properties": {
    "distinct_id": "018f3c…",
    "token": "phc_a1b2…",
    "$session_id": "018f3c…",
    "$current_url": "https://example.dk/pricing"
  }
}

One vendor, four tools in the panel

Since Event Watcher v1.5.0 the PostHog product family is split into separate named tools, so a site running the full stack shows up to four PostHog tools in the panel instead of one aggregate entry:

• PostHog Analytics: the /e, /capture and /batch event traffic described above, plus the /decide and /flags config calls.
• PostHog Session Replay: the recording pipeline, matched on the dedicated /s/ ingest path (including the versioned /i/v1/s/ routes) and the recorder script bundles, versioned or not.
• PostHog Feature Flags: flag evaluation and experiments. It has no endpoints of its own: the config calls stay under PostHog Analytics, and the Flags tool appears when the SDK reports a flag exposure event on the analytics pipe.
• PostHog Surveys: popover and widget surveys, matched on the surveys.js script bundle (versioned paths included).

The split also separates consent expectations: Analytics and Session Replay are checked against analytics consent, while Feature Flags and Surveys count as functional.

Debugging PostHog with Event Watcher

• Classifies each PostHog request by endpoint type (capture, decide/flags, script load) and routes replay, flag and survey activity to its own named tool, so config chatter and recording bandwidth don't read as event volume.
• The parser decodes the base64 form data and unpacks /batch arrays into individual events with name, distinct_id, and full properties.
• Because $autocapture events all share one name, the Grouped view pivoted by Event Name plus the decoded $elements data is the practical way to see what actually got clicked.
• Detection is URL-pattern based: a self-hosted instance or a first-party reverse proxy (a setup PostHog itself encourages for ad-blocker resilience) won't match the posthog.com patterns, so events on such sites surface as raw requests rather than under the PostHog name.

PostHog and consent

The extension checks PostHog against the analytics consent category. PostHog offers opt_out_capturing() and a cookieless/memory persistence mode, but there is no consent-mode-style degraded ping: a /e request before an analytics grant is a genuine pre-consent event, flagged and counted.

The subtle case: /decide fires on SDK init before consent. It is a config fetch, not an event, but it does transmit the distinct_id, which is worth knowing when writing up an audit.

Common debugging scenarios

• Event volume looks huge. Pivot Grouped view by Event Name to check how much is $autocapture and $pageleave before assuming custom instrumentation is double-firing.
• Flags behave differently than expected. Find the /decide//flags config calls in the stream (they stay under PostHog Analytics) to confirm they happen, and when, relative to your first $pageview; actual flag exposures surface under the separate PostHog Feature Flags tool.
• Identity splits across sessions. Compare distinct_id before and after the $identify event in the stream.
• EU project, US traffic. Verify hits target eu.i.posthog.com and no stray snippet still points at the US host.
• Nothing detected on a site you know runs PostHog. Look for a first-party proxy. The requests will still be in the stream as uncategorized calls with the familiar base64 data shape.