What PostHog Debugger can detect
Understand the PostHog requests and SDK state the extension can inspect, along with its important limits.
What the extension recognizes
PostHog Debugger observes PostHog ingestion and state traffic from normal HTTP and HTTPS pages. It recognizes common cloud, self-hosted, and reverse-proxied endpoint shapes, including /i/v0/e/, /e/, /batch/, /capture/, /decide, /flags, and /s/.
It decodes supported event payload forms, including ordinary JSON, batches, form-encoded data, base64, and gzip where the browser exposes usable bytes. It can also read live configuration, flags, identity, session, replay, and autocapture data when the page exposes a compatible window.posthog instance.
What a missing event means
The panel only sees activity after its hook is installed. Reload the page with DevTools open before treating a missing startup event as an SDK problem. A missing event can also be hidden by a paused capture, active Events filter, browser or network blocker, custom proxy path, or browser restriction.
Important limits
Session-recording /s/ requests are noted for delivery diagnostics, but their large rrweb payloads are not decoded into the event inspector. The Flags & Session, Identity, and Autocapture surfaces depend on the inspected page exposing a readable window.posthog; Events and Network can still work without it.
The extension runs where the browser permits its content script. Browser-protected pages, restricted schemes, and some extension pages or frames can prevent injection. Iframe coverage depends on the browser allowing the extension to run in that frame. Test an equivalent top-level HTTP or HTTPS page when frame traffic is absent.
Custom endpoints
Reverse proxies are recognized by endpoint shape, not only hostname. If a proxy rewrites PostHog paths into an unrecognized custom shape, the extension may not classify the traffic. Record the request path from DevTools Network and include it in a support report.