Igor
Session replay is a good way to see what a user did. For many bugs it is not enough, because the cause is not on screen. It is in what the server returned, in an error thrown a few lines away, or in one element the user would have to describe.
What a replay shows
A replay shows the clicks, scrolls, navigation and input leading up to the report, and the page as it changed. That answers "what did they do?" and often "what did they see?" It is the fastest way to turn a vague report into repro steps.
What it does not show
- What the server returned. A replay shows a blank screen after "Place Order." It does not show whether the response was a 422 with an error message, or a 200 with the wrong data.
- Which element the user meant. Someone watching a replay still has to guess which of three buttons was wrong.
- The error and where it came from. A console error with a file and line is the shortest path to the code.
- Anything the agent can read. A coding agent cannot watch a video. It needs text: steps, an element, a request and an error.
What to pair it with
| Evidence | What it answers |
|---|---|
| Session replay and repro steps | What did the user do? |
| The element, with errors tied to it | Which part of the page was wrong? |
| Requests with request and response bodies | What did the server send, and did the page use it correctly? |
| Console errors with file and line | What threw, and where? |
SnagRelay attaches all four to one report. The replay covers the moments before the report; how long depends on your plan. The error moment is marked on the timeline, so you jump to it instead of scrubbing.
Replay for a human, steps for an agent
The same replay is turned into repro steps. A developer can watch it, and get_issue_context returns the steps, the element, the errors and the requests to Cursor, Claude Code or Codex over MCP.