Session replay has a reputation problem, and it is largely deserved.
The category was defined by analytics tools that record every session of every user continuously, forever, so that a growth team can scrub through someone's checkout flow next quarter. That is surveillance with a debugging feature attached, and users are right to be uneasy about it.
We use replay anyway, because for one class of bug nothing else works. But we use it differently.
Where replay is the only tool
Most bugs are solved by the console and the network log. An error, a 500, done.
Then there is the other kind. Console clean. Network clean. Every request returned 200. And the user is completely certain something broke.
They are almost always right. What broke was the interaction — a click that landed on the wrong element, a form that silently reset, a modal that opened behind an overlay, a state transition that left the UI in a shape you never anticipated. None of that produces an error, because from the code's perspective nothing went wrong.
For those, the replay is the whole investigation. You watch the twelve seconds before the report and see what they actually did, which is regularly not what they described.
Scoped to a report, not to a user
The core difference: our replay is attached to a bug report, not to a user profile.
Recording exists to explain a specific submitted report. It is not building a longitudinal record of anyone's behavior. There is no session browser, no "watch a random user," no funnel analysis. If nobody reported a bug, nobody is watching anything.
This is a smaller feature than analytics-tool replay. That is the point. The narrow version solves the debugging problem without the part that makes people uncomfortable.
The user holds the redaction tool
The screenshot annotator includes a blur tool, and it works the way it should: redaction happens in the browser before upload. A blurred region is not blurred on our servers — it never reaches them.
This inverts the usual arrangement. Normally privacy is a promise from the vendor: we say we'll handle your data responsibly, and you decide whether to believe us. In-browser redaction is not a promise. The pixels do not leave the machine.
Practically, it means a user looking at a page full of customer names can send you the screenshot you need. Without it, the careful ones send nothing.
Off by default, where it counts
captureNetworkBodies is false unless you turn it on.
Bodies are useful — sometimes the response payload is the entire bug. They are also where tokens, personal data, and payment details live. The safe default is the one where turning it on is a decision someone made deliberately.
Replay itself is one line to disable, whether globally or on the routes that shouldn't be recorded:
Bugdump.init({
apiKey: 'your-api-key',
features: {
sessionReplay: false,
},
});Every capture feature works this way — screenshots, recording, replay, and attachments each toggle independently. You can run BugDump with nothing but a description and a console log if that is what your compliance posture requires.
The permission prompt we chose to keep
Screenshots and recordings default to getDisplayMedia, which shows the browser's own permission dialog. We could avoid it entirely by defaulting to DOM rendering.
We kept it, for two reasons.
The fidelity is real — canvas, video, cross-origin iframes, and native controls all captured exactly as rendered, rather than approximated. And the prompt is honest. The user is told, by the browser rather than by us, that their screen is about to be captured. They can decline, and declining falls back to DOM capture rather than losing the report.
A permission dialog is friction. It is also consent, delivered by a party neither of us controls.
Where we land
Replay is a powerful tool that the analytics industry taught people to distrust. The distrust is reasonable and the tool is still worth having.
Our answer: scope it to reports rather than sessions, put the redaction tool in the user's hands and run it before upload, default the riskiest capture off, and make every feature disableable in one line.
You get the twelve seconds that explain the bug. You don't get a surveillance system, and neither do we.