A Vercel preview deployment is the best test environment you have and the least tested. It is the build that will ship, running at a URL, before anyone has merged anything. Drift takes the paths your users actually recorded in production and replays them against that preview; if a recorded path fails, the pull request gets a BLOCK.
What already runs on your preview, and what it can't see
Most teams on Vercel point three things at a preview: the end-to-end tests they wrote, a Lighthouse or bundle check, and sometimes a visual diff. All three are worth keeping. All three test what somebody thought to write down.
Your e2e suite covers the paths an engineer decided were important, on the day they decided it. A screenshot diff catches pixels that moved, not behaviour that broke while the pixels stayed put. None of them know that returning users reach for a particular control from muscle memory, or that a three-step flow is completed in one specific order by nearly everyone who completes it.
This matters more now because a growing share of frontend PRs are written by coding agents. An agent satisfies every objective it can observe: tests pass, types check, spec met. It cannot observe your users. The characteristic failure of agent-authored code is a change described accurately in the PR and a side effect on a surface the PR never mentions.
Behavioral drift, defined
Behavioral drift is when a change breaks how users navigate a product without breaking the code. Users learn a product: which control, which order, which step comes next. When a change disturbs that learned behaviour, the path still technically works, but people hesitate, retry, backtrack, or abandon. Nothing in CI catches it, because nothing in CI knows what users do.
How replay against a preview works
Drift keeps a behavioral load map of your product, built from real recorded sessions: which elements carry interaction, which sit in the path of goal completions, and how ritualised returning users are around them. That map powers the probabilistic signals every PR gets on every tier.
Path replay is the second, deterministic tier. When a PR has a preview deployment, Drift replays real recorded user journeys against it in an isolated container, then discards the container. If a path that succeeded in production fails on the preview, the check reports path_broken and the verdict is BLOCK.
Two things about that verdict are deliberate. It is the only verdict that fails a check; load-map signals warn and advise but never block, so a quiet CLEAN is a real result rather than a miss. And it is overridable. You stay in charge of the merge; the check exists so you choose with evidence.
Every number in the check comes from sessions, manifests, or replay runs. No model guesses a verdict. The result is one sticky comment on the PR, edited in place, shown only at WARN or BLOCK.
What you need in place
- A session source. If you already run PostHog or Sentry session replay, connect it; no new script on your site. Otherwise the UXSense recorder is one line.
- The GitHub App. It posts the check on your pull requests and detects releases. [VERIFY: confirm the GitHub App is also how Drift learns a PR has a preview deployment, or whether Vercel's deployment status on the PR is read separately.]
- Vercel preview deployments on. [VERIFY: whether any Vercel-side setting, integration install, or environment variable is required for Drift to reach the preview URL.] [VERIFY: how Drift handles Vercel Deployment Protection (password or Vercel Authentication on previews); whether a bypass token or protection exception is needed.]
- Drift Team. Path replay against preview deploys, and the Vercel / Render preview integration, are Team tier at $19 per checked seat per month. A seat is a human whose PR got a check this period; bots and coding agents are never billed. Load-map signals, BEHAVIOR.md, and unmetered checks are on Free.
Setup for the first three is in Getting started. [VERIFY: whether a Vercel deploy webhook is needed for previews or only for production release detection; Connections lists deploy webhooks but the help docs describe them only for releases.] [VERIFY: typical replay time and when the sticky comment moves from pending to a verdict.]
What it will not do
It replays what your users have done. A flow nobody has completed yet has no recorded path, so the deterministic tier is silent on it and you are back to the tests you wrote. Coverage is reported on every check; icon-only buttons and heavily dynamic text can fall through, and the build-time stamp takes coverage to near-total. Canvas interiors and cross-origin iframes are out of scope. The first signal needs around 30 sessions, so a product with no traffic yet has nothing to replay.
Replay is a check on the behaviour you already have, not a substitute for writing tests for the behaviour you are about to add.
FAQ
Does this replace my Playwright or Cypress suite on the preview? No. Your suite tests the paths you chose to write. Replay tests the paths your users chose to take. They overlap less than you would expect.
What happens on a PR with no preview deployment? The probabilistic tier still runs: load, stereotypy, and unclaimed-surface signals from what the PR changes. Only the deterministic tier can block, so without a preview there is no BLOCK.
Is any of my preview data kept after the run? No. Replays run in isolated containers and keep nothing after the run. Session data is not used to train generalised models.
Start with the free tier
Install Drift Free, connect the sessions you already have, and read the load-map signals on your next few PRs. When you want preview replay, Team is a seat price and seats add themselves.