If PostHog records your sessions, you can check every pull request against what your users actually do without adding a recorder to your site. Connect a PostHog personal API key to UXSense, install the GitHub App, and Drift scores each PR against a behavioral load map built from the replays PostHog already holds. The first thing to do after connecting is run a backtest on your last release: the backtest runs in minutes and shows what Drift would have said about your last release.

Why the replays are not enough on their own

Most teams running PostHog have session replay switched on and nobody watching it. The recordings pile up, and the one time somebody opens them is after support has already reported the problem. That is the wrong end of the process. By then the deploy that caused it has been followed by two more, and everyone in the thread has a different theory about which one did it.

The gap is structural. CI checks code against code. Your test suite knows what the code is supposed to do. Neither of them knows which button carries most of your checkout completions, or that returning users reach for the sidebar link from muscle memory. That knowledge lives in the replays. So the useful question is not "should we watch the replays" but "how do we get the replays to look at the PR before it merges."

What behavioral drift is

Behavioral drift is when a change breaks how users navigate a product without breaking the code. The path still technically works. People hesitate, retry, backtrack, or abandon a step they have taken a hundred times, because the thing they learned to do is no longer where they learned it. Dashboards stay green, error rates stay flat, and nothing in CI notices, because nothing in CI knows what users do.

What UXSense reads from PostHog

UXSense reads the rrweb event streams PostHog stores for each recording, along with the recording's metadata: duration, click counts, the person's distinct ID. Recordings are fetched on demand during analysis, and the calls are rate-limited well inside PostHog's API limits. Nothing polls continuously, and disconnecting stops all reads immediately.

From those streams UXSense builds a behavioral load map: a deterministic model of which elements your users depend on. How much interaction each one carries, whether it sits in the path of a goal completion, and how ritualised returning users' behavior around it is. Every figure in that map is computed from sessions. No model guesses a number.

Connecting

You need 3 things from PostHog:

  • A personal API key, which starts with phx_, with access to session recordings. Create one under Settings, then Personal API keys.
  • Your project ID, visible in the project URL or settings.
  • Your host, only if you are on EU cloud or self-hosted. US cloud is the default.

In UXSense, go to Connections, then PostHog, then Connect. Paste the key and project ID and save. UXSense verifies access and shows the connected project and organization on the card.

Before that, when you create the project, set 2 or 3 goals: the flows that matter, such as checkout completed or report generated. Goals drive the rest. Reports measure them, and Drift protects the paths that complete them.

Run the backtest first

The moment PostHog is connected you can run a backtest from the Drift page. UXSense reads a sample of your historical recordings, rebuilds the load map as it stood before your last release shipped, and scores that release's pull requests against it. The output is what Drift would have said before you shipped.

2 limits, and both are printed on every backtest report. First, path replay does not run on history. The deterministic tier needs a live preview deployment, and a shipped release's previews are gone, so backtest verdicts use the probabilistic signals only and cap at WARN. Second, coverage is what it is. The report states what share of interactions resolved to stable element identities. Installing the UXSense build plugin stamps your components and takes coverage to near-total for future checks, but the backtest works on whatever PostHog already captured.

Backtest recordings are fetched transiently and never stored. Only the derived map, aggregate weights per element with no replay content, is retained.

What a check looks like on a live PR

Install the GitHub App and it does 2 jobs: it detects releases automatically, so impact reports appear without manual entry, and it posts Drift verdicts on pull requests.

Each PR gets one of 4 verdicts. CLEAN means the PR touches nothing carrying meaningful user load, and most PRs should land there. ADVISORY means worth a glance: the change touches a surface users rely on that the PR description does not mention, or returning users interact with the element ritually and muscle memory is about to break quietly. WARN means a high-load element in the path of a goal completion was removed, renamed, or plausibly disturbed. BLOCK is the deterministic tier only: a recorded real-user journey failed when replayed against the PR's preview deployment. It is the one failing verdict, and you can override it.

The model's only job is reading the PR description to work out what was claimed. The verdict comes from sessions, manifests, and replay runs. UXSense posts one sticky check comment, edited in place, and only at WARN or BLOCK. A clean PR gets a quiet check, not a comment.

What it costs

Checks are unmetered on every tier, including free, and free is an ongoing tier rather than a trial. Only human PR authors count as seats. Bots and coding agents never bill. Your first Release Impact Report ships at 30 sessions; with PostHog connected you do not have to wait for it, because the backtest runs on history.

FAQ

Does this replace PostHog session replay? No. PostHog keeps recording exactly as it does now. UXSense reads those recordings and adds a PR-time check on top. Disconnect any time from the same card.

Do I need to add the UXSense recorder if I have PostHog? No. PostHog is a complete session source. The optional UXSense build stamp only raises coverage by giving elements stable identities; it is not required to run checks.

Will my agents' PRs get checked? Yes, and they are the ones that most need it. Agent-authored code satisfies the spec and has no idea what users depend on. Agents are never billed as seats.

Can a check block a merge? Only BLOCK does, and only when a recorded journey fails against the PR's preview deploy. Probabilistic signals warn and advise; they never block. Every BLOCK is overridable.

Connect PostHog and run the backtest on your last release. See how Drift checks work.