Your agents can't see your users.
Drift maps what your users actually do, then checks every pull request against it. When a change breaks a path real users depend on, it says so, before it's merged.
All your tests pass, you ship, and a week later checkout conversion is down and nobody can say which change did it.
That's behavioral drift. Drift catches it before it's merged.
Know what your users depend on
Drift builds a Behavioral Load Map from real sessions. Every element is scored by the traffic and completions it carries, and by how ritualized returning users are about reaching for it.
Catch drift before merge
Every pull request is checked against the map. Results land on the PR in ~20 seconds.
Your users wrote these tests
Real recorded paths, replayed against your preview deploy. It's a pass or fail, no judgment calls.
A spec that can't go stale
One command writes BEHAVIOR.md from real sessions, the loaded elements, the muscle-memory surface, the paths that must keep working. Your agents read it before every edit.
Agents fix it before you see it
The check output is machine-readable. Your agent reads it, corrects the change, and pushes, often before a human even opens the PR.
Quiet by default
A clean PR is a green check and nothing else. If there’s something to say, it’s one comment, edited in place every push.
Pairs with your reviewer
CodeRabbit, and other code review agents, asks whether the code is good. UXSense asks whether users can still use it.
Nothing here is guessed
Every figure is computed from recorded sessions. The model reads your PR description to work out what you claimed; it never writes a number.
A PR check has five parts. Most have two.
Every automated PR check runs on the same skeleton: something starts it, it does something, and then, in the ones that work, it finds out whether it was right, remembers the answer, and knows when to say nothing. Here's where the parts come from in UXSense.
Signals earn their place
Every prediction is graded against the release that ships it. Signals that don't predict real behavior change are removed automatically.
Start from the sessions you already have.
If you're already recording sessions, Drift has everything it needs today. If you're not, it takes about 30 recordings. Here's exactly what happens either way.
Install the snippet
One line in your app. Drift starts recording sessions immediately. Inputs are masked by default.
Your first load map
Enough traffic to know which elements carry completions and which are decoration. You'll get a load map and a BEHAVIOR.md you can commit.
Connect GitHub
Drift starts checking pull requests against the map. Connect Vercel or Render too and it replays real user paths against your preview deploys.
Install the build plugin
Stamps components at build time so Drift tracks elements through refactors instead of guessing. Not required, but precision improves.
Priced for the way code gets written now.
Free
Free for up to 3 seats. Unmetered checks, unlimited repos. Not a trial.
- Unmetered PR checks
- Behavioral Load Map + BEHAVIOR.md
- Load, stereotypy, and unclaimed-surface signals
- 30-day session retention
- Sampled above 5,000 sessions/mo
Team
A seat is a teammate whose pull request got a Drift check this period. Seats add themselves, nothing to assign. Bots and coding agents are never billed.
- Everything in Free
- Path replay against preview deploys
- Vercel / Render preview integration
- Build-time stamping plugin
- 90-day retention · unsampled to 50,000 sessions/mo
No per-review fee and no hourly rate limits.
Get startedEnterprise
SSO, security review, DPA, SLA, custom retention.
- Security review + DPA
- Custom retention
- Account management
Both products, one price.
Combine Drift Team + Releases Growth for one flat fee, includes up to 6, 20, or 50 checked seats. At 20 seats ($449/mo) Release reports are practically free.
Drift checks pull requests before merge. Releases tells you what actually happened after you shipped.
Annual: 10× monthly — 2 months free
FAQ
What is behavioral drift?
Users learn your product — which button, which order, which step comes next. Behavioral drift is what happens when a change breaks that learned behavior rather than the code: the path still technically works, but people hesitate, retry, backtrack, or abandon. Nothing in CI catches it, because nothing in CI knows what your users do. Drift catches it by checking every pull request against recorded behavior — before merge.
Does this replace my code reviewer?
No, and it doesn't overlap with one. CodeRabbit-style review asks whether the code is good. Drift asks whether the change breaks something users have learned to do. Teams run both.
What if the check is wrong?
Blocking failures are overridable — a recorded path breaking is sometimes exactly the point of the PR. Everything below that tier is advisory. And every prediction is graded against what actually happened after the release shipped, so a signal type that doesn't predict reality gets demoted or removed rather than sitting there being wrong.
Won't this be another bot commenting on everything?
Clean PRs get a green check and no comment. Drift comments only at warn or block, and edits that one comment rather than stacking new ones. It stays quiet because there's usually nothing to say — most pull requests don't touch loaded surface at all.
Do I need the build plugin?
No. Without it Drift identifies elements semantically — role, accessible name, position in the flow. The plugin makes identity survive refactors, which improves precision on codebases that move fast.
What about single-page apps / iframes / canvas?
Single-page apps work: client-side route transitions are treated as distinct pages, and dynamic URLs collapse into one route — /order/123 and /order/456 are the same page as far as the load map is concerned. Same-origin iframes are captured; cross-origin frames (a Stripe checkout, an embedded video) can't be read by any browser and are excluded — by browser security, not by us. Canvas is the honest limit: Drift sees that users click a canvas, not what happens inside it, so canvas-heavy apps read lower coverage — and every check discloses its coverage figure. Low coverage makes Drift quieter, never wrong.
How is this different from session replay tools?
Replay tools show you what happened — and lately, AI summaries of what happened. Either way, that's an account, after the fact. Drift computes what all your sessions have in common, checks every pull request against it before merge, and grades its predictions against the release that ships. An observer tells you what it saw; a measurement knows when it was wrong.
Every pull request, tested against what real people actually do.
Install the recorder this afternoon and the load map starts building from your real sessions. A few days later, every merge gets checked against it. The clock starts when the snippet does.
Free for 3 seats · No credit card required