Session replay (what the visitor did before the bug)
Session replay answers the question a developer asks after every vague bug report: what exactly did the person do before it broke? In Bugfix the visitor presses one button inside the report form, repeats the problem on the page, and the recording travels to your team together with the message.
How Bugfix records what the visitor does
Session replay in Bugfix starts with the 🎬 button in the bug report form. It records the actions of the visitor on the page with the rrweb library. rrweb does not film the screen. It records the changes of the page itself, the DOM: the tree of elements that the browser builds from the page, with its buttons, texts and forms.
- The visitor opens the form with the floating button of the widget.
- The visitor presses 🎬 and acts on the page.
- The visitor sends the message.
- The recording goes into the private storage
bug-replaysand is attached to that message.
What a developer sees next to a session replay
A session replay does not arrive alone. In the same message the developer finds:
- the screenshot of the screen;
- the marked element, with its selector and frame;
- console errors;
- network requests;
- the last steps of the user.
Taken together, these show what the person was doing before the problem appeared, so the developer reads the sequence of actions instead of a one-line complaint. Messages are collected in the developer dashboard at /dashboard.html, which opens by token.
Who can open a recording
Recordings are private. The file lies in the closed storage bug-replays and is tied to one message. It opens through the protected function for viewing attachments, not through a public link, and without the owner's token it does not open at all.
The same rule covers every private attachment in Bugfix: screenshots, screen recordings and voice messages are all served through that function.
Where a recording of the visitor's steps is useful
- A bug that depends on the order of actions. A report that says “the page freezes” tells nothing about the path to the freeze. A session replay shows the path, and the last steps of the user sit beside it.
- A visitor who cannot describe the steps. The person does not have to write them down: it is enough to repeat the actions with the recording on.
- A problem tied to a device or browser. The device and browser are part of the same message, so the developer sees where the recording was made.
Turning on session replay on your site
The recording button belongs to the report form, so session replay appears on a site together with the Bugfix widget. The widget is added with one script tag that carries the key of your site in data-project, and the loader keeps it up to date on every site.
If the content security policy of your site is strict, allow blob: in img-src and media-src. Without it the preview of the recording will not show.
Limits of the recording
- Recording starts only when the visitor presses 🎬: the recording script is not even loaded before that. Ordinary technical context of the report, such as console errors, network requests and the last steps, is attached to the message separately.
- Private attachments cannot be opened without the owner's token.
- The security policy of the site has to allow helper resources of the
blob:type, otherwise the preview stays empty. - The recording is a log of page changes, not a video. A picture of the screen comes from the screenshot in the same message.
Frequently asked questions
Is session replay in Bugfix a video of the screen?
No. rrweb records changes of the DOM, the structure of the page, and not a video of the screen. The picture of the screen comes from the screenshot attached to the same message.
Does Bugfix record a visitor's session without asking?
No. The page recording is started only by the visitor pressing the 🎬 button in the report form, and the recording script is loaded at that moment. The usual technical context of the report, such as console errors, network requests and the last steps, travels with the message separately.
Where is a recording stored and who can open it?
It is stored in the private storage bug-replays and attached to the message. It opens through the protected viewing function with the owner's token, not through a public link.