Yes. PostHog has a Session Replay product that records what real users do in your website or app and plays it back with a synced DevTools panel showing console logs, network requests and errors. It runs on recordings captured by PostHog's SDKs, and you can sample or mask what gets recorded.
Yes, with developer detail alongside the video
The docs describe session replay as recording what real users do in your product and playing it back like a DVR. Next to the playback sits a synced DevTools panel with console logs, network requests and errors, so a developer can see exactly what broke at the moment a user got stuck.
Because PostHog already captures events, every replay is enriched with the person, their properties and the feature flags they had switched on. That's the real advantage: you can jump from a drop-off in a funnel, or from an exception, straight to the session behind it, instead of guessing which recording to watch.
Where you can watch replays
- In the PostHog web app.
- By asking PostHog AI to find and summarise replays for you.
- In your code editor, pulled in over MCP.
- Through an API that can list, filter, update and delete recordings and playlists.
Getting recordings started
Replay runs on recordings captured by PostHog's SDKs, which cover web, React Native, iOS, Android, Flutter and more. Once the SDK is installed, recording starts the moment a user lands on the page. The install wizard runs with npx -y @posthog/wizard@latest if you'd rather not set it up by hand.
Choosing which sessions to record
You don't have to record everything, and on a busy site you won't want to. Recording rules use trigger groups: URL triggers, event triggers and a feature flag. Each group has its own sample rate, minimum duration and an ANY or ALL match type, and a session is recorded if it matches any trigger group.
In practice, that lets you record every session on your checkout page, a sample of sessions elsewhere, and every session for users in a new feature's beta. Trigger groups need posthog-js 1.369.0 or later, and creating or editing them needs project admin permissions.
Mobile replay has limits web doesn't
PostHog Docs are open about this: web has the most complete feature support. Mobile platforms have limits such as wireframe-only mode unless screenshot mode is switched on, and no keyboard capture. So a mobile replay may show the layout and taps without a pixel-perfect picture of the screen. The docs also note that the newer trigger-group rules need posthog-js 1.369.0 or later and fall back to legacy controls on older versions, so check your SDK version before you rely on them.
What stays private
Input elements are masked by default, so typed details aren't captured unless you change that. You can set maskAllInputs to false and mask only chosen input types, such as password fields, if you need to see other entries. Privacy controls run in the browser or mobile app, so masked data is never sent over the network to PostHog in the first place.
That matters for any business handling personal details. Leave the default masking on unless you've a clear reason to change it, and if you switch it off, make sure passwords and payment fields stay masked.
Turning replays into fixes
Replays are only useful if someone watches the right ones. Save the sessions that show a problem into a playlist, share it with whoever owns that page, and note the console error or failed request from the DevTools panel next to it. That way a developer isn't starting from a vague complaint; they're starting from the exact moment it broke, with the person's properties and flags already on screen.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
How Hotjar compares
Hotjar's session replay page lists event-triggered recording to capture sessions tied to specific behaviours, and error analysis that ranks replays containing errors by their impact on conversion. If heatmaps are part of what you need, my list of the best heatmap tools compares the options, and this guide to using product analytics shows how replays fit alongside funnels and events.
My verdict for product teams
If you already use PostHog for analytics, switch replay on and lean on trigger groups: record every session on the pages where money or sign-ups happen, and sample the rest. Start from funnel drop-offs and errors rather than random recordings. Keep input masking on, check your posthog-js version, and expect less detail from mobile than from web.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Does PostHog record mobile apps?
Yes, through its SDKs, with some limits compared with web.
Can I record only some sessions?
Yes, using trigger groups with URL, event or feature flag conditions and a sample rate.
Are passwords recorded?
Input elements are masked by default, and masking runs in the browser, so masked data isn't sent to PostHog.
Can I watch replays outside the web app?
Yes. PostHog lists MCP and API access as well as the web app.
What does a replay show beyond video?
A synced DevTools panel with console logs, network requests and errors.
