Session replay in PostHog Web

The PostHog web app is where you watch replays. Open Replay and you get a filterable list of recorded sessions on the left and a player on the right, with an activity timeline that stays in sync with playback. Because replays sit on the same data layer as your events, every recording already carries the person, their properties, the feature flags they had, and any exceptions they hit.

That's the difference between a video and a debugging environment. You can jump to the moment an error fired, read the console output from that instant, and inspect the network waterfall around it without asking the user to reproduce anything.

Before you start

1. Set up Session Replay – install and enable recording so there are sessions to watch.
2. Open the web app – no install needed, just sign in to PostHog.

What you can do here

• Watch recordings – play back a session with the synced activity, console, and network panels.
• Filter and build collections – filter by rage clicks, dead clicks, exceptions, custom events, person properties, or feature flag variant, then save the result as a collection or a saved filter playlist.
• Share and embed replays – send a teammate a link to an exact timestamp, or embed a replay elsewhere.
• Find replays with PostHog AI – describe the behavior you're looking for in plain language and let PostHog AI build the filters. This is an interaction mode inside the web app, not a separate surface.
• Summarize a recording with Replay Vision – have Replay Vision watch a recording and write up what the user did.
• Jump in from other PostHog tools – open the replays behind a funnel step, a feature flag variant, or an error tracking issue.

Self-driving reports

A scout reads your recordings for the moments users get stuck, clusters those moments into a report with the replays that prove it, and routes it to a human reviewer in the Self-driving inbox. To get these reports, set up Self-driving.

Unlike error tracking, this scout stops at the report. It doesn't open a draft pull request.

How a session problem becomes a report

The scout watches two things: whether you're still recording, and where recorded users hit a wall.

• Capture cliffs – recording volume falling away while site traffic holds, usually an SDK change, a blocked recorder script, or a sampling or quota change. These are urgent because recordings can't be captured retroactively, so every silent day is gone for good.
• Confusion – the user clearly couldn't work out what to do next
• Abandonment – they gave up partway through a flow
• Failures – an action didn't do what the user expected
• Blocking and non-blocking exceptions – errors that stopped them, and errors they worked around

Individual bad sessions aren't very actionable, so these get clustered across sessions. What makes a cluster worth your time is concentration: friction spread thinly across a product is just baseline, while friction piling up on one page or element, measured against that surface's own history, is a real finding. Each report names the surface, quantifies the step against its baseline, dates when it started, and links a few example recordings you can watch.

Because this analysis is done by AI, it only runs once your organization has approved AI data processing. Until then the session replay signal source stays off. See signal sources for how to turn it on.

Why there is no pull request

A replay shows you the symptom, not the cause. A rage-click cluster on one button could be a slow request, a mislabeled control, a disabled state that gives no feedback, or a genuine bug – the recordings prove people are struggling there, but working out which of those it is takes a human. And a capture cliff is almost always a configuration or deployment problem, not a defect a coding agent could patch.

So the scout files each finding as an investigation with the evidence attached and a reviewer assigned, and stops there. You can still hand a report to an agent once you've decided what the fix should be. Other signal sources, like error tracking, do open pull requests on their own.

What you can do with a report

• Read the report – the pattern, how many users and sessions hit it, when it started, and the replays that prove it.
• Watch the evidence – each report links example recordings, so you can see the problem rather than infer it from a number.
• Ask questions – start a discussion with an agent about the report to dig further before you act.
• Follow the activity – the report's activity log shows what happened to it and when.
• Decide what happens next – fix the capture config, redesign the step, hand it to an agent, or dismiss the report. Nothing happens until you decide.

Related

• Search the same sessions from your editor over MCP.
• Pull recordings and playlists into your own systems with the API.
• Not seeing the sessions you expect? Check troubleshooting.