Webclat / PostHog Practice

The two PostHog health checks worth running before you trust the data

Authorized URLs and web vitals are easy to skip because neither one is required to get PostHog capturing events. Both catch a class of problem that otherwise surfaces months later as bad data or an unanswerable performance question.

Authorized URLs: who is allowed to send you data

The authorized-domains list controls which URLs PostHog will accept certain interactions from (notably, toolbar access and some autocapture behaviors). Without it locked down, a project key that leaks - copied into a public repo, exposed in a client-side bundle without scoping - can be used to send events from anywhere, or a staging/dev environment can pollute production project data if it was pointed at the wrong project key during setup.

This is a five-minute check with a real payoff: confirm the authorized list matches your actual production and staging domains, and nothing else.

Web vitals: performance data you already have half of

Web vitals autocapture sends Core Web Vitals (load performance, interactivity, visual stability metrics) as PostHog events, joined to the same session and person context as everything else. The advantage over a separate performance-monitoring tool is the same as with error tracking: you can segment performance by the same cohorts, feature flags, and funnels you already use for product analysis, instead of a disconnected performance dashboard.

CheckWhat it catchesHow often to re-check
Authorized URLs listLeaked project keys, stray dev/staging traffic in production dataWhenever a new environment or subdomain goes live
Web vitals autocapture enabledMissing performance data entirely - it is opt-in, not automatic, on most SDK versionsOnce at install; re-check after major SDK upgrades

Exact toggle locations and default states for both features move between PostHog versions - verify current defaults against PostHog's own docs rather than assuming either is on by default in a fresh install.

How to verify it worked

  1. Attempt to load the toolbar or send a test event from a domain not on the authorized list and confirm it is actually rejected - a list that exists but is not enforced correctly gives false confidence.
  2. Check a production page's session in PostHog for web vitals properties on the pageview event - if they are absent, autocapture is not actually enabled for that page or SDK version.
  3. Cross-check one web vitals number (e.g., largest contentful paint) against a browser devtools performance trace on the same page load, to confirm the captured value is in a sane range rather than a misconfigured metric.

Frequently Asked Questions

Is the authorized-domains list a security feature?

It restricts what certain PostHog capabilities (like toolbar access) will respond to for a given domain - useful hygiene, but it is not a substitute for keeping API keys out of public code in the first place.

Do web vitals cost extra to capture?

Web vitals are captured as regular PostHog events, so they count against the same event-based usage as everything else - factor that into volume planning rather than treating it as free telemetry.

Get a health check before you trust the dashboard.

A short audit of authorized domains and web vitals capture, alongside the rest of an install review - catches the quiet problems before they show up as a data question nobody can answer.

Run My Health Check