A replay is a reconstruction, not a video
The most common misunderstanding about session replay is that it records the screen. It does not. A replay captures the DOM — the structure of the page — plus every change to it, along with clicks, scrolls, input events, network timings and console errors. Playback rebuilds the page from that data in your browser.
That distinction is the whole point. Because a replay is structured data rather than pixels, you can search it, jump to the exact moment an error fired, and read the DOM state at that instant. A screen recording gives you none of that, and costs far more bandwidth to collect.
What it gives you that a stack trace does not
An error tracker tells you a TypeError was thrown on line 214. It does not tell you that the user had already submitted the form twice, that the second attempt was on a slow connection, or that the button stayed disabled afterwards. Replay supplies the sequence of events that produced the state your code choked on.
In practice this collapses the slowest part of debugging: reproduction. Instead of guessing at steps from a one-line bug report, you watch the path the user actually took.
How to use it when a bug comes in
Work backwards from the failure rather than forwards from the session start. Find the error in your monitoring, open the linked replay, and jump to the timestamp. Then scrub backwards thirty seconds — the cause is almost always in the half-minute before the symptom, not at the beginning of the session.
Check three things in order: what the user clicked immediately before, whether any request failed or hung, and whether what they saw on screen matched what you expected to render. Most bugs resolve on one of those three.
What it will not solve
Replay shows you what happened, never why the person did it. If a user abandons a form, the recording tells you which field they stopped at — it cannot tell you whether the question was confusing, intrusive or simply too long. That answer comes from asking them.
It is also poor at aggregate questions. One recording is an anecdote. If you need to know how often something happens, that is a funnel or an event query; use replay to explain the drop, not to measure it.
Choosing one for debugging specifically
If debugging is the job, weigh three things above everything else. Console and network capture — without them you are watching a silent film. Error-to-replay linking, so an exception takes you straight to the session that produced it rather than a list to search. And privacy controls granular enough to keep the tool useful: masking every input protects users but can hide the exact value that triggered the bug, so look for field-level rules rather than an all-or-nothing switch.