Session replay for bug reports
See the minutes before a user wrote to you: clicks, navigation, rage clicks and the console at the moment it broke. Inputs are always masked.
Included on Free · Screen recording on Pro
The session behind ticket NT-248, playing: fifty-seven seconds recorded in three segments, with one interval unavailable because the page was hidden. The reporter reaches the checkout, applies the coupon SPRING24, and the discount appears without the total changing. Paying answers 500 twice; they rage-click three times and open a report. Beside the player, the same session as a log of twenty entries — clicks, requests, a stale-totals warning and an uncaught TypeError — with the row under the playhead highlighted as it plays.
How it works
1
Recording starts with the page
A full snapshot, then every mutation, pointer move, scroll and masked input, flushed every ten seconds under a fixed budget.
2
The report freezes the buffer
The last minutes attach to the ticket with console and network.
3
Your team scrubs the film
The player runs the session beside the log, and clicking a line seeks to it.
Reproduce without asking
Beside the film runs the same session as a log — every click, request and console error in order, coloured by level. Steps to reproduce stop depending on the reporter's memory.
A render of the console and network log inside a ticket in the panel. One console error and two failed requests landed in the twenty-two seconds before the report, and the nine entries are listed with their timestamps: a warning that the cart totals were stale, two POSTs to /api/cart/discount that returned 500, an uncaught TypeError raised in applyDiscount, and the clicks between them. Errors are red, warnings amber, requests teal until they fail.
Honest about what it could not capture
When the widget stands down under host load, or a page is too large to snapshot, the ticket says so: the interval it missed, why it missed it, and the recording that stopped at its own ceiling. Nothing is stitched over.
What the ticket reports about a recording that stopped early: the evidence strip with the screenshot and a partial recording of one minute, the note that recording stopped at max duration, and under them the session's own account of the interval the replay paused for while the report was being written, with the two diagnostic codes the widget wrote for it.
Exact behaviour
- Capture
- Full DOM snapshot, then mutations, pointers, scroll and masked input; flushed every 10 s
- Retention
- Idle sessions and their replay 90 days; captured logs 30 days; tickets are never removed by retention
- Privacy
- Input masking always on; secrets scrubbed from logs; mask and block rules per selector
- Browsers
- Chromium, WebKit, Firefox; desktop and mobile
- Plan
- Free and Pro
- MCP tool
- get_ticket · list_sessions · get_session · get_masking_rules
Works with
Questions teams ask before installing
Does replay record what users type?
No. Input masking is always on and is not a setting, so a replay carries the shape of a form and never the characters typed into it.
How much CPU does it use on the host page?
Recording runs under a fixed budget and suspends itself when the host page shows degradation signals. The widget never blocks the host page's paint or input.
Can I turn replay off, or keep part of a page out of it?
Replay belongs to a project's capture settings, so it is switched on or off per project — in the panel or with the update_project_settings MCP tool. Inside a page the unit is the selector, not the URL: mask selectors, block selectors, scrub keywords and a mask-everything switch, read with get_masking_rules and changed with set_masking_rules. Those rules can only ever reduce what is captured.
See the replay on your own site today.
Free plan includes session replay.