PostHog events not showing in a Vite app on Vercel
In a Vite app deployed on Vercel, missing PostHog events usually stop in one of five places: the project key was not in the build, because Vite fixes VITE_ variables when it builds; api_host points at the wrong region; a browser blocker stops requests to PostHog; route changes in a single page app are not sent as pageviews; or you are looking at a different project or through a filter. Check them in that order with the browser network panel and the activity view in PostHog.
Why this matters
Reviewed on 14 October 2026 against PostHog, Vite and Vercel docs. No test events were sent to a PostHog project for this page, so the procedure below is a manual diagnostic recipe, not an observed customer result. One real case shaped step 6: while writing it, the analytics connection we had open pointed at another organization's project, so every query for our own site returned nothing.
Find where the events stop
- Open the deployed page with ?__posthog_debug=true added to the URL. PostHog's SDK reference says debug mode logs every PostHog call to the browser console. No PostHog log and no request in the network panel usually means posthog.init never ran.
- If init never ran, check the key in the build. Vite replaces import.meta.env.VITE_ values when it builds, so a key added in Vercel after the build is not in the bundle. Add the variable your code reads, such as VITE_PUBLIC_POSTHOG_KEY, for the Production or Preview environment you are testing, then create a new deployment. Vercel applies variable changes to new deployments only.
- Check that api_host matches your project's region: https://us.i.posthog.com for US Cloud, https://eu.i.posthog.com for EU Cloud. Events sent to the other region's host do not land in your project.
- Check for blockers. A request marked as blocked by the client in the network panel was stopped by an extension, not by PostHog. Turn the blocker off to confirm. For production traffic, PostHog documents a managed reverse proxy and a Vercel rewrites proxy; its Vercel guide says Vercel bills the proxied traffic and warns against obvious paths such as /analytics or /posthog.
- Check single page app pageviews. PostHog captures a pageview on the first page load. Route changes in a single page app need capture_pageview set to history_change, which a recent defaults date sets, or your own $pageview call on each route change. With capture_pageview: false, only the pageviews your code sends exist.
- Check where you are looking. Compare the token in your build with the one in the PostHog project settings, pick the right project, widen the time range to include now, and turn off filters such as the one for internal and test users before you decide nothing arrived.
- If your site sends a Content-Security-Policy header, allow PostHog: PostHog's install guides list https://*.posthog.com for script-src and connect-src.
Optional repo check
For AI-built Vercel + Supabase apps, an optional check lists environment variables the code reads that .env.example does not list. In a run of npx -y viberaven@1.6.8 check on a Vite + Vercel + Supabase fixture repo on 2026-10-14 it reported VITE_PUBLIC_POSTHOG_KEY as a variable the code reads that .env.example does not document. It cannot see which variables are set in your Vercel project or whether events arrive in PostHog. It is advice, not a gate, and a repository check, not a live database or security test. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore.
Confirm one event from the deployed site
This is a proposed manual procedure, not an observed customer result. Use a site and a PostHog project you own, a test account and no customer data. It confirms that one event from one deployment reaches one project; it does not measure how many events are lost.
Read the symptom
| What you see | Look at |
|---|---|
| No PostHog request and no debug log | The key in the build (step 2) |
| A request blocked by the client | A browser extension, then a reverse proxy (step 4) |
| Requests succeed but nothing appears | The region host, the project token and the filters (steps 3 and 6) |
| Only the first pageview appears | Single page app pageviews (step 5) |
Send one event you can find
Open the deployed URL, not a local build, in a fresh browser profile with blockers off. Do one action your code captures, such as a button click with a custom event, and note the time. In PostHog, open the activity view for the same project, look for that event name in the last few minutes and check that its $host and $current_url match the deployment you opened.
Then repeat with blockers on
Repeat the same action with your usual extensions on. If the event arrives only with blockers off, the setup works and the gap is blocking, which a reverse proxy addresses. Write down the date, the deployment URL and the event you checked.
Related guides
Sources
Why does PostHog work locally but not on Vercel?
Your local dev server reads the key from your local .env file. The Vercel build only has the variables set for that environment when it ran, and Vite copies VITE_ values into the bundle at build time. Add the key in Vercel for the right environment and redeploy.
Why does PostHog show only the first pageview in my React app?
In a single page app the browser loads one page and the router changes the URL after that. Set capture_pageview to history_change, which a recent defaults date sets, or send $pageview yourself on each route change.
Do ad blockers stop PostHog events?
Some do. Confirm by testing with blockers off. PostHog documents a managed reverse proxy and a Vercel rewrites proxy so requests go through your own domain.