free · no signup
PostHog installation checker
Check if PostHog is installed on your site, flag duplicate or render-blocking loads, then confirm events arrive in your PostHog project.
Scans the page's HTML in seconds. It also reports every other tracking script it finds.
about PostHog
Why it breaks quietly.
PostHog's browser snippet calls posthog.init with your project API key and an api_host. It captures page views, autocaptured clicks, custom events and session recordings for product analytics.
The common failures are configuration, not installation. The script loads, but events go to the wrong region, page views are missed on client-side routes, or an ad blocker eats every request, and the project just looks quiet.
what the free scan checks
Whether PostHog is in the page
The scan fetches the page's HTML and matches the vendor's script URL and install snippet.
Whether it blocks rendering
A script tag without async or defer delays the page from painting. Marketing scripts never need to.
Whether it's installed more than once
Duplicate installs usually send every event twice and inflate conversions.
How exposed the page is to blockers
A server-side readiness grade: whether tags load from domains blocklists target, and whether conversions have a server-side path.
It reads the HTML, so tags injected later (inside GTM, for example) don't show up, and it can't see events fire. That's what verification is for.
common failures
How PostHog goes dark.
api_host points at the wrong region
A project on PostHog's EU cloud needs the EU host and a US project needs the US host. A mismatch means events are sent and never land in your project.
Single-page apps miss page views
Without history-change page view capture or manual $pageview calls on route changes, PostHog records one page view per load instead of one per screen.
Ad blockers block PostHog's domains
Common block lists include PostHog's hosts. A reverse proxy on your own domain is PostHog's recommended fix.
Two inits with different keys
A snippet in the layout and a second init in app code, sometimes with a dev project key, send events to two projects or create confusing duplicate sessions.
by hand
Check it yourself, step by step.
- 1
Open your PostHog project's Activity view and watch for your own events as you browse in another tab.
- 2
In the browser console, run posthog.debug() and reload to see PostHog log each event it captures.
- 3
In Chrome DevTools, filter the Network tab for your api_host and confirm requests succeed rather than failing or being blocked.
- 4
Navigate between routes on a single-page app and confirm a $pageview arrives for each one.
questions
Asked and answered.
Can this check tell me if PostHog events are firing?+
No. The scan reads your served HTML and can see whether PostHog's script or init call is present, duplicated or render-blocking. It cannot see PostHog loaded at runtime or confirm events reach your project. TracerKit's Verification tier watches real fires and reconciles counts against PostHog.
Why is PostHog showing no events?+
Check the project key, then that api_host matches your project's region, then whether a blocker or content security policy is stopping the requests.
Should I proxy PostHog?+
If a meaningful share of your audience runs ad blockers, yes. PostHog documents reverse proxy setups for common hosts.
check other tags
Know PostHog is firing, every hour of every day.
Verification watches each tag on real traffic and emails you the moment one goes silent. 14-day trial, no card.