If Sentry already records your sessions, you have the data to check a pull request against real user behavior before it merges. UXSense reads those replays, builds a map of which elements your users depend on, and posts a verdict on the PR. Nothing new goes on your site.

Most teams use replay the other way round. Something breaks, a ticket lands, someone opens Sentry and scrubs through a session until they see the moment the user gave up. The replay is doing forensics. It's very good at it, and it's always late.

What behavioral drift is

Behavioral drift is when a change breaks how users navigate a product without breaking the code. Users learn a product: which button, which order, which step comes next. A pull request moves the button, reorders the steps, or renames the thing they reach for, and every test still passes, because tests describe what the code should do, not what people have learned to do. The flow still works. People hesitate, retry, backtrack, or abandon. Dashboards look normal for days.

Why the incident is the wrong time to open replay

A replay after an incident answers one question: what did this user see? That's useful. By the time you're asking it, though, the deploy is out, 2 more have followed, and the argument about which one caused it has already started.

The same recordings answer a better question if you ask it earlier. Which parts of the interface carry the load? Which elements sit in the path of a completed checkout or a saved report? Which ones do returning users hit from muscle memory without reading? That's a property of your sessions in aggregate, not of any one replay, and it's exactly what a pull request needs to be checked against.

What UXSense does with Sentry sessions

UXSense builds a Behavioral Load Map from real recorded sessions: for each element, how much interaction it carries, whether it sits on a goal-completion path, and how ritualized returning users' behavior around it is. The map is deterministic. No model guesses a number. Every figure comes from sessions, manifests, or replay runs.

With the GitHub App installed, every pull request is scored against that map. Most land as CLEAN, and a quiet check is a real result. A PR that touches a surface users rely on but doesn't mention it in the description gets an ADVISORY. A high-load element that's removed, renamed, or plausibly disturbed gets a WARN. The only failing verdict, BLOCK, comes from the deterministic tier: a recorded user flow replayed against the PR's preview deployment, and failed. That tier needs a preview deploy, and you can override it. You stay in charge of the merge.

The check posts one sticky comment, edited in place, and only at warn or block. Checks are unmetered on every tier, including free.

Connecting Sentry

The connection lives under Connections in the UXSense app. [VERIFY: exact Sentry credential type, where to create it in Sentry, required scopes, and whether it is org-level or project-level.] Once connected, UXSense reads session replays. [VERIFY: which Sentry Replay fields and event streams are read.]

[VERIFY: whether Sentry recordings are fetched on demand during analysis, as they are for PostHog.] Only the derived map is retained, which is aggregate weights per element with no replay content. [VERIFY: whether the historical backtest, documented for PostHog connections, is available from a Sentry connection.]

Your first check needs enough sessions to build a map. The first report ships at 30 sessions. [VERIFY: whether Sentry-sourced sessions count toward that threshold the same way PostHog and recorder sessions do.]

Coverage, stated honestly

Every check carries a coverage figure: the share of observed interactions that resolved to stable element identities. Sentry replays weren't recorded with UXSense's build stamp, so elements resolve by semantic anchors: role, accessible name, and route. That covers a lot. Icon-only buttons and heavily dynamic text can fall through. Installing the UXSense build stamp takes coverage to near-total for future checks. Low coverage makes checks quieter, never noisier, so you won't get a warning the data can't support.

FAQ

Do I have to stop using Sentry Replay for incidents? No. UXSense reads from it and doesn't replace it. Forensics after the fact and checks before merge use the same recordings to answer different questions.

Does UXSense store my Sentry replays? Session data is not used to train generalized machine-learning models, and personal data is not sold. Retention for Sentry-sourced sessions specifically is not yet documented. [VERIFY: retention behavior for Sentry-sourced sessions, and whether they follow the plan's retention window like recorder sessions.]

What if my coverage is low? Checks get quieter, not noisier. The coverage figure is on every check so you can see what the verdict rests on, and the build stamp closes the gap.

Can this block a merge? Only the deterministic tier can, and only when a recorded flow fails against a preview deployment. It's overridable.

Point the recordings at the pull request

Connect Sentry, install the GitHub App, and once the map has enough sessions, every PR gets checked against what your users actually do. See how Drift verdicts work.