Core Web Vitals show up in two different places. One is real users: metrics from the browser, fed by an analytics SDK. The other is scheduled tests: Google’s PageSpeed machinery runs on a URL you choose, on a cadence you set.
PostHog is the first kind for performance. Its Web Vitals live under Web Analytics and use the same posthog-js SDK as the rest of product analytics. Apogee Watcher is the second kind: multi-tenant PageSpeed monitoring on the PageSpeed Insights API—Lighthouse lab data plus CrUX where Google publishes it—for teams covering many sites without putting a script on every domain.
PostHog is a strong product stack (flags, replay, experiments, warehouse analytics). We are not building that. PostHog’s Web Vitals module also does not replace synthetic monitoring for sites you never instrument, and it does not include Watcher’s automated discovery, performance budgets, or agency RBAC by default. The decision is which problem you are solving first—and whether you need both.
What PostHog Web Vitals actually is
PostHog’s docs describe Web Vitals autocapture for FCP, LCP, INP, and CLS via Google’s web-vitals library. You turn on Web vitals autocapture in project settings (separate from generic autocapture) and run posthog-js v1.141.2 or newer. Events are named $web_vitals, with properties such as $web_vitals_LCP_value per metric.
The UI is built for analysts: Web Analytics → Web Vitals gives trends, the same filters as the rest of Web Analytics, and a URL table in good / needs improvement / poor buckets against PostHog’s thresholds (same bands as web.dev). You can view p75, p90, or p99; PostHog recommends p90 as a balance between signal and noise. The toolbar shows vitals for the page you are on plus history for that page—handy while you debug in product.
That scope is intentional: PostHog gives you Core Web Vitals metrics and trends for product analytics—it does not replicate a full PageSpeed Insights or Lighthouse lab report. You do not get the complete Lighthouse output from a PSI-style run: audit categories, opportunities, diagnostics, performance score breakdown, and the rest of the structured result you would see after calling the PageSpeed Insights API. For that depth you need a synthetic lab run (or another tool that runs Lighthouse end to end), not $web_vitals events alone.
Operationally, the SDK batches vitals (a few seconds’ flush by default). You can sample $web_vitals in before_send if billable events are a worry. PostHog suggests roughly 30 $web_vitals events per 100 $pageview events on average; vitals bill like any other event—see pricing.
Cookieless mode. With PostHog’s cookieless tracking (cookieless_mode: 'always', or the cookieless branch of on_reject), posthog-js does not send usable $web_vitals data: each vitals payload needs session and window IDs, and in these modes the usual session path is not there, so metrics are dropped. If you run banner-free always cookieless, do not expect a filled Web Vitals dashboard from PostHog alone—you give up that slice of analytics depth on purpose. SDK details change; check PostHog’s docs when you upgrade.
You only measure visitors who load the snippet and whose sessions allow vitals (consent, ad blockers, cookieless settings, whether the page ran long enough to emit metrics). That fits your product when capture is on. It does not cover dozens of client domains you never instrument, or a prospect URL before you have access.
Budgets and email alerts: how much setup each tool expects
PostHog has no monitoring-style “CWV budget” object—no per-URL LCP/INP/CLS cap with a built-in schedule and cooldown the way ops teams mean “budget.” You explore vitals in the Web Vitals UI; alerts hook onto trends insights in Product Analytics.
To get “email when this metric crosses a line,” you build or open a trend that plots the right series (often from $web_vitals fields), pick the series the alert watches, set a fixed or relative threshold, choose a check interval (hourly to monthly), and add email, Slack, or webhooks. Goal lines on the chart can match the threshold, but you are still in the insights product—not “add a budget for this URL” in one step. Someone has to keep those insights valid when events, filters, or properties change, and to align percentiles and sampling with what you are alerting on.
Watcher puts performance budgets and email next to scheduled PageSpeed tests for the org, site, or page you already track—no trend model first. Cooldowns are there to reduce alert noise for ops, not for funnel review. That is synthetic + CrUX only; it does not replace PostHog alerts on signups, revenue, or anything non-PageSpeed.
Teams deep in PostHog often fine-tune vitals insights and alerts and are right to. If the job is “keep client sites inside CWV limits with little glue,” a monitoring product usually means fewer steps.
What Apogee Watcher optimises for
Apogee Watcher is monitoring-first, not analytics-first. We run scheduled PageSpeed tests via Google’s API, store history per organisation, site, and page, and surface lab and CrUX together so you can see both “what Lighthouse saw” and “what Chrome users experienced at scale” when CrUX has data for that URL. You do not deploy our code on your clients’ sites to get baseline monitoring—we hit public URLs from Google’s test infrastructure.
That design choice matters for agencies:
Add staging or production URLs even when marketing controls the tag manager and will not add another script.
Organisations, sites, pages, and Admin / Manager / Viewer roles match how agencies staff work—not one analytics property per product.
Sitemap and HTML crawl so new templates and landers are not stuck behind a manual URL list.
Budgets and alerts aimed at “tell us before the client’s CWV drifts for a week,” not funnel charts.
Leads Management for new business: prospect URL, one-page reports, time-limited share links, score-band outreach—revenue workflows, not session analytics.
We do not ship a full product analytics stack, session replay, or feature flags. If you need those, use a tool built for them—often PostHog.
Side-by-side: where the overlap ends
Topic | PostHog (Web Vitals) | Apogee Watcher |
|---|
Primary job | Product analytics OS; Web Vitals are real-user metrics from the browser | Synthetic PageSpeed monitoring + CrUX in results |
Instrumentation | Requires `posthog-js` on the site | No script on monitored sites |
Metrics | FCP, LCP, INP, CLS from real sessions (`$web_vitals`) when capture runs — not a full Lighthouse/PSI audit payload | Lighthouse lab + CrUX (where available) via PSI (full Lighthouse context per scheduled run) |
Cookieless analytics | With `always` (and cookieless paths without session IDs), `$web_vitals` does not populate—see Cookieless mode above | No snippet; tests do not use PostHog session state |
Best for | “How do my users experience my app?” | “How are these URLs doing on a schedule—and across many clients?” |
Multi-site agency | Analytics projects and teams—not Watcher’s org/site/page model | Multi-tenant orgs, roles, discovery, budgets |
Budgets & email alerts | Insight-based—build trends from `$web_vitals`, attach [alerts](https://posthog.com/docs/alerts) with thresholds, frequency, destinations; maintain as analytics evolves | Monitoring-native—performance budgets and email alerts tied to scheduled tests; no separate insight to curate first |
Extras | Flags, replay, experiments, cohorts, warehouse pipelines | PDF-style reporting direction, Leads prospecting workflows |
Cost shape | Event-based (vitals count toward event quotas) | Plan-based subscription; PSI quota bundled—verify [pricing](/pricing) |
Use the table as a decision grid, not a spec sheet. Both products change; verify details on each vendor’s site before you buy.
When PostHog is the better primary choice
Choose PostHog when you own the app, already want product analytics, and need real-user vitals next to releases, experiments, and segments. If the question is “did that React change hurt INP for paying customers on Safari?”, you want RUM inside analytics—not only a nightly PSI run.
Feature flags and experiments sit next to Web Vitals, so you can tie score moves to what shipped. We do not replace that layer.
When Apogee Watcher is the better primary choice
Choose Watcher when synthetic coverage and agency workflow matter more than in-app events:
You watch many client or third-party sites where you will not (or cannot) deploy PostHog for a baseline.
You want scheduled checks, regressions, and budgets even when traffic is quiet this week.
Automated discovery matters because CMSs and URL lists change constantly.
You sell retainers and need client-ready reporting plus role separation (internal vs customer).
For the upgrade story from manual checks, see PageSpeed Insights vs Automated Monitoring. For setup at scale, How to Set Up Automated PageSpeed Monitoring for Multiple Sites tracks the same workflow we care about.
The complementary stack (layer, do not replace)
For many agencies the practical setup is both: PostHog (or similar) for behaviour and real-user vitals on sites you control, plus Watcher for multi-site synthetic monitoring, CrUX where Google provides it, and prospecting workflows. Different questions:
RUM alone can miss pre-launch or zero-traffic URLs. Synthetic alone can miss logged-in or heavy-JS interaction pain. Together they cover more ground.
If you already use PostHog, what does Watcher add?
You already have $web_vitals, charts, and optional trend alerts—except in cookieless setups where vitals do not fire (see above). Watcher does not copy flags, replay, or experiments. It adds:
CWV signals when PostHog cannot send vitals. Cookieless always (or the no-session cookieless branch) leaves the Web Vitals view empty. Watcher still runs scheduled PSI + CrUX on the URLs you care about—independent of cookies, consent, or snippet load.
Scores without traffic. PSI can run on a timetable when visits are rare, the page is new, or the build is on staging without production tagging. PostHog needs visitors; Watcher needs a public URL.
Sites with no PostHog. Retainers, handovers, marketing-owned stacks, or prospects before contract: you still get lab + CrUX from Google without another analytics install per domain.
Portfolio shape. Orgs, sites, pages, Admin / Manager / Viewer, and sitemap + crawl discovery match “many clients, many URLs,” not one analytics project per product.
Monitoring alerts. Thresholds and email on test results and cooldowns, without building a trend per metric (see Budgets and email alerts above).
Sales workflows. Leads Management—prospect URL, one-page report, share link, score-band outreach—where PageSpeed is part of new business, not product analytics.
Two lenses on one site. On your own marketing site you can compare browser RUM with scheduled lab + CrUX. When they disagree, that is often lab vs field vs session—useful, not contradictory.
Watcher is not a second analytics product. It adds external monitoring, agency access control, and stored synthetic history next to what PostHog already does.
Limitations we will not sugar-coat
Watcher is not session replay, funnels, or feature flags.
PostHog Web Vitals are event streams from the browser, not a full PSI/Lighthouse audit (see What PostHog Web Vitals actually is). Watcher’s stored PSI runs include full Lighthouse context on a schedule—lab plus CrUX—when you need that bundle. In cookieless PostHog setups where *$web_vitals never lands**, you have no CWV series in PostHog at all—**synthetic monitoring** (here or elsewhere) is how you keep scores without changing your privacy settings.
Cookieless PostHog and Watcher work side by side: your analytics privacy choice does not block server-side PageSpeed tests.
CrUX needs enough real Chrome traffic; quiet URLs may show no field data. RUM, CrUX, and lab can disagree—that is normal.
Bottom line
PostHog’s Web Vitals docs cover real-user vitals for teams on the SDK. Watcher covers scheduled synthetic + CrUX for teams running many URLs and client-facing workflows. Decide on coverage (script or not), question (users vs URLs), and org model (analytics project vs agency portfolio)—then use one tool or both.
If Watcher matches how you work, check pricing and features for solo operators and agencies—including what is live for Leads Management—before you assume every seat gets full prospecting access.
FAQs
Is Apogee Watcher a PostHog alternative?
No. PostHog is product analytics; Web Vitals are one part. Watcher is PageSpeed / CWV monitoring across portfolios. Use neither, one, or both.
Does PostHog replace scheduled Lighthouse monitoring?
No for URLs you never instrument, or environments with no traffic. Synthetic runs still matter.
Does Watcher replace real-user vitals?
No. RUM captures post-load behaviour (SPAs, logged-in flows). CrUX helps at URL level when Google has data; it is not full RUM.