PostHog events not showing? A browser debugging checklist

Start here: find where the event disappears

PostHog Debugger is an unofficial DevTools extension that helps separate a browser capture problem from a PostHog project problem. Install it from the Chrome Web Store or Firefox Add-ons, then follow Getting started if you have not completed a clean first capture.

Steps

1. Open DevTools and the PostHog panel before loading the page you want to inspect.
2. Reload the page, confirm capture is not paused, and clear all Events filters.
3. Reproduce one action that should create a known event.
4. Compare Config, Events, and Network using the panel reference.

Expected observation

• No SDK state and no request usually points to initialization, consent, blocking, or a browser execution problem.
• An event in Events without a successful request points to delivery, endpoint, proxy, or browser policy problems.
• A successful request that never appears in the expected PostHog project points to project, region, filtering, ingestion, or identity lookup problems.

Limitation

The extension only observes activity after its page hook is installed. It cannot reconstruct startup requests sent before DevTools was opened, and a custom endpoint shape may not be classified even when the browser sends it.

Next action

Start with the browser-side checks below. Move to project-side diagnosis only after you can show that the browser created a plausible PostHog request.

Browser-side diagnosis

Confirm that the SDK initialized

Steps

Open Config and check the loaded state, SDK version, project token, API host, capture settings, and configuration warnings. Compare the result with the official PostHog JavaScript SDK installation guide and the initialization code deployed to this environment.

Expected observation

The SDK is loaded once, uses the intended public project token, and sends to the correct PostHog Cloud region, reverse proxy, or self-hosted host. The deployed environment should not have skipped posthog.init because of an environment guard or missing public configuration value.

Limitation

Some applications use a named PostHog instance or do not expose a readable window.posthog. In that case Config can be incomplete while Events and Network still observe traffic.

Next action

If the SDK is absent, fix initialization or the environment configuration before investigating PostHog. If Config is unavailable but requests exist, continue with the request and payload checks.

Confirm that the browser created a request

Steps

Reproduce the event and inspect Network for recognized ingestion paths such as /i/v0/e/, /e/, /batch/, or /capture/. Check the request URL, method, status, and timing. Use the browser's built-in Network panel as a second view when nothing is classified by the extension.

Expected observation

A request is created soon after capture or batch flush and reaches the intended host. A 2xx response shows that the endpoint accepted the HTTP request; a blocked entry, browser error, timeout, CORS failure, or non-2xx response gives a browser-side lead.

Limitation

A 2xx response does not prove that the event completed PostHog's ingestion pipeline. Batching can also delay delivery, and unloading a page can change the transport or timing.

Next action

If there is no request, check consent, runtime errors, and blockers. If it fails, investigate the reported browser or server error. If it succeeds, inspect the payload before moving to project-side checks.

Inspect the event payload

Steps

Select the event in Events and review its event name, project token or api_key, distinct_id, properties, warnings, and raw payload. Match it to the corresponding request in Network. For batches, confirm the expected event is actually one of the batch entries.

Expected observation

The payload has a non-empty event name, the intended public project token, a usable distinct ID, and valid JSON or supported encoded data. The values should match the environment and user you are testing.

Limitation

The extension cannot decode every byte the browser may send. Large session-recording payloads are noted but not expanded into ordinary events, and unsupported compression or a custom envelope can leave only request-level evidence. Review what PostHog Debugger can detect before treating a missing decoded event as a missing request.

Next action

Correct malformed or environment-mismatched values in the capture call. If the payload looks correct and the request succeeds, preserve a sanitized copy for the project-side checks.

Check consent and opt-out state

Steps

Review consent and opt-out details in Config, then reproduce the consent-management flow. Check whether opt_out_capturing_by_default, posthog.opt_out_capturing(), a consent manager, or application logic prevents capture before the user opts in. PostHog documents these controls in Controlling data collection.

Expected observation

When a user is opted out, manual captures, autocapture, and session replay are not sent. After valid consent and opt_in_capturing(), new events can create requests.

Limitation

Opt-out state can persist in browser storage or cookies, so a code change or page reload may not reset the test device. Consent requirements are application-specific; the extension reports state but cannot decide when capture is legally appropriate.

Next action

Fix the application's consent transition or test with a fresh, authorized test profile. Do not bypass real user consent to improve event counts.

Check identity changes

Steps

Open Identity and compare the current distinct ID, device ID, identified state, and timeline with the expected login, identify, alias, and reset flow. Use PostHog's identifying users guide to verify stable IDs and logout behavior.

Expected observation

Anonymous events use the current device identity, authenticated events move to the intended stable user ID, and logout calls reset before another user begins a session.

Limitation

An identity mistake usually does not prevent ingestion. It can make an event appear missing because it is attached to a different person, anonymous ID, or merged identity.

Next action

Correct the identify/reset sequence, then search PostHog using the exact event name and distinct ID from the captured payload.

Isolate CSP, ad blockers, and privacy tools

Steps

Look for blocked requests, CSP console errors, browser shield messages, or extension interference. Confirm that connect-src permits the ingestion host and, when needed, script-src permits PostHog assets. Reproduce the issue in a clean browser profile or temporarily allowlist only your controlled development site.

Expected observation

The same action produces a request in the clean test profile. If the normal profile still blocks it, the blocker or browser policy is the cause rather than PostHog project configuration.

Limitation

Development allowlisting is only a diagnostic step. Users can choose to block analytics, and production tracking must respect their browser and consent choices.

Next action

Fix an incorrect CSP. If first-party delivery is appropriate for the product, evaluate PostHog's official reverse proxy guidance instead of relying on users to disable protection.

Verify reverse proxies and self-hosted endpoints

Steps

Read the actual URL and path in Network and compare them with the SDK api_host, proxy routing, and upstream PostHog host. Test TLS, CORS, redirects, and the final status. For self-hosted installations, confirm that the configured public host reaches the intended instance and review the official self-hosting documentation.

Expected observation

The public endpoint accepts the ingestion path without an unexpected redirect, preserves the request body and method, and forwards to the correct Cloud region or self-hosted service.

Limitation

PostHog Debugger recognizes common endpoint shapes, not every custom rewrite. A proxy can deliver an event successfully while the extension leaves it unclassified. The extension also cannot inspect proxy or self-hosted server logs.

Next action

Correct the SDK host or proxy rule. If the custom path works but remains unclassified, record the path and include it in a PostHog Debugger support report.

Rule out browser and extension capture failures

Steps

Reload with DevTools already open, unpause capture, clear Events filters, and repeat the test on a normal top-level HTTP or HTTPS page. Check whether the original page is browser-protected, an extension page, a restricted scheme, or a cross-origin iframe where injection is unavailable.

Expected observation

The equivalent top-level page produces visible activity after reload. If only a restricted page or frame fails, browser execution rules explain the difference.

Limitation

Browser-protected pages cannot be made observable by changing PostHog configuration. Frame coverage depends on the browser granting the extension access to that frame.

Next action

Use the browser's Network panel for traffic the extension cannot inspect, or reproduce the integration on an equivalent permitted page before reporting a capture bug.

PostHog project-side diagnosis

Verify the project, region, and token

Steps

Compare the token and destination host from the captured request with the project settings you are viewing. Confirm that US Cloud, EU Cloud, a reverse proxy, and a self-hosted instance are not being mixed across environments.

Expected observation

The request token belongs to the open project and its destination ultimately resolves to that project's region or instance.

Limitation

PostHog Debugger can show the token and host used by the page, but it cannot authenticate to PostHog or prove which private project a token belongs to.

Next action

Correct the deployed public token or host, reload with DevTools open, and send a fresh uniquely named test event.

Check filtering, warnings, and ingestion health

Steps

Review PostHog ingestion warnings, event-filtering apps or transformations, and the PostHog status page when successful requests are delayed. Follow PostHog's official Product Analytics troubleshooting guide for direct-request and reporting steps.

Expected observation

The project has no rule intentionally dropping the event, no active ingestion warning explains it, and the service is not reporting a relevant incident.

Limitation

Temporarily disabling project processing can affect production data. A successful browser response can precede ingestion or query availability, especially during an incident.

Next action

Test project changes only with appropriate access and a controlled event. If an incident is active, preserve the evidence and retry after recovery instead of changing browser code.

Search with the captured event and identity

Steps

Search recent events using the exact event name, timestamp, and distinct ID from the payload. Remove unrelated insight filters and widen the time range enough to cover clock or ingestion delay. Check both the event stream and the relevant person's activity.

Expected observation

The event appears under the captured distinct ID even if it was absent from a filtered insight or attached to an unexpected identity.

Limitation

Browser timestamps, project time zones, identity merges, and saved insight filters can change where an event appears without changing whether it was ingested.

Next action

Fix the identity or query configuration when the raw event exists. If it remains absent, continue with ingestion or self-hosted server diagnosis.

Diagnose the self-hosted ingestion service

Steps

Confirm the instance is current and healthy, then inspect reverse-proxy and PostHog service logs for the request time, path, status, and project token. Verify that the ingestion service, queues, storage, and query path used by the deployment are operating.

Expected observation

Server-side logs trace the accepted request into the intended project without proxy rejection, queue failure, or storage error.

Limitation

Self-hosted infrastructure is operated outside the browser and outside PostHog Debugger. The extension cannot validate deployment health, data pipelines, or server retention.

Next action

Escalate with the instance operator using sanitized browser evidence and server logs. Follow the self-hosted project's own operational and upgrade process rather than treating the issue as an extension failure.

Prepare a safe support report

Steps

Record the extension version, browser version, page type, expected event, actual endpoint shape, HTTP status, Cloud region or self-hosted environment, and whether the issue survives a clean reload. Export only the minimum event JSON, HAR, or cURL evidence needed to reproduce the failure.

Expected observation

The report makes clear whether the SDK failed to initialize, the browser failed to send, the payload was wrong, the extension could not classify the request, or PostHog did not surface a successfully sent event.

Limitation

Debugging artifacts can contain URLs, authorization headers, cookies, distinct IDs, event properties, and other sensitive values. Remove secrets and personal data before sharing. Do not send production payloads to third-party request-inspection services.

Next action

Use PostHog support for confirmed SDK, project, Cloud, or ingestion problems. For an extension capture or classification problem, use the PostHog Debugger support page or open a GitHub issue with the sanitized evidence.

Privacy and further reading

PostHog Debugger processes inspected debugging data locally and does not send captured payloads to the developer. Read the PostHog Debugger privacy policy before exporting or sharing data, and keep the concise troubleshooting and privacy guide available for general extension capture and data-handling questions.

Use the PostHog debugging tools comparison to decide when browser Network tools or the official PostHog Toolbar should take over. For extension changes that affect the evidence described here, review the complete changelog.