Screenshot, video, HAR, or session replay: which evidence for which bug

Evidence is what turns your bug report from a claim into a fact. But there are five or six kinds of evidence, and attaching the wrong one wastes everyone's time.

A three-minute video of you clicking around is not helpful when a single annotated screenshot would show the problem. Equally, a screenshot proves nothing about a bug that only appears during a sequence of actions.

This guide helps you choose quickly.

Short version

Screenshot: anything you can see on one screen.
Video: anything that involves a sequence, timing, or animation.
Console log: anything where the page misbehaves without an obvious cause.
Network log or HAR: anything involving data, loading, or a server.
Session replay: bugs found by real users, after the fact.
Attach at least two types for anything above minor severity.

The quick decision guide

If the bug is...	Attach
Visual — layout, colour, spacing, text	Annotated screenshot
Wrong number or wrong text on screen	Annotated screenshot
A crash or blank page	Screenshot + console log
Something that happens during a sequence	Short video
Timing, animation, or flicker	Short video
Data missing or wrong after loading	Network log (HAR) + console
Slow performance	Network log + timing numbers
An error the user never sees	Console log + network log
Reported by a real user in production	Session replay + error tracking entry
Mobile app crash	Crash log + device details

Screenshots

Best for: anything visible on one screen at one moment.

Screenshots are the fastest evidence to produce and the easiest to read. Most bug reports should have one.

Make them useful:

Capture the whole window, including the browser address bar. The URL is part of the evidence.
Annotate it. Draw a red box or arrow around the problem. An un-annotated screenshot makes the reader hunt.
Add a second screenshot of the correct state, when one exists. Before and after, side by side, removes all argument.
Include the console in the frame if there are errors, or attach it separately.

Where screenshots fall short: they cannot show sequence, timing, or anything that happened before the moment of capture. If your description contains the words "then", "after", or "while", you probably need a video.

Videos and screen recordings

Best for: sequences, timing problems, animations, and anything you struggle to describe in words.

Make them useful:

Keep them short. Under 60 seconds. Ideally under 30.
Start just before the problem, not five minutes earlier.
Move slowly and deliberately. Fast clicking is hard to follow.
Do not narrate with audio unless your team is comfortable with it. Text in the report is searchable; audio is not.
Still write the steps. A video is not a substitute for written steps, because nobody can copy and paste from a video, and search engines and ticket search cannot read it.

Where videos fall short: they are large files, they are slow to watch, and they do not show what happened under the surface. A video shows a blank page; it does not show the JavaScript error that caused it.

Console logs

Best for: anything where the page behaves strangely and you cannot see why.

The browser console records errors from the code running in the page. Open it with F12 (Windows and Linux) or Cmd+Option+I (Mac), then choose the Console tab.

Make them useful:

Open the console before reproducing the bug. The console does not record what happened before it was opened. This is the number one mistake.
Copy the text, do not just screenshot it — text is searchable and developers search their code for exact error strings.
Include the full stack trace, not only the first line. Click the arrow to expand it.
Include warnings, not only errors, if there are few of them.

A console error transforms a bug report. "The page went blank" is a symptom. "The page went blank and the console shows TypeError: Cannot read properties of undefined (reading 'map') at dashboard.js:1:88213" is close to a diagnosis.

Network logs and HAR files

Best for: anything involving data, loading, saving, or a server.

The Network tab shows every request the page makes. A HAR file (HTTP Archive) is a saved copy of that whole log, which you can attach to a ticket.

To save one in Chrome: open DevTools → Network tab → reproduce the bug → right-click in the request list → Save all as HAR with content.

What to look for before you attach it:

Requests shown in red — these failed
Status codes: 400s mean the request was wrong, 500s mean the server broke
Requests that took a long time
Responses that are empty when they should contain data

Make them useful:

Tick "Preserve log" before reproducing, or the log clears on page navigation.
Point to the specific request in your report. Do not make the reader search a 400-entry file. Write: "See POST /api/cart/totals — returns 200 with an empty body."
Check for secrets before attaching. HAR files contain headers and cookies, which means they contain authentication tokens and sometimes personal data. Many teams require HARs to be sanitised, and there are free tools that strip sensitive fields.

That last point is important enough to repeat: never attach a raw HAR from a production session with real user data.

Session replay

Best for: bugs that real users hit in production, which you did not see yourself.

Session replay tools record what users did — clicks, page changes, and often console and network activity — so you can watch it afterwards.

Strengths: you get evidence for bugs nobody reported, and you see exactly what the user did rather than what they say they did.

Limits:

Most tools mask input fields for privacy, so you may not see what was typed
Recordings expire, often after 30 days
They usually do not include server-side information
Watching them takes real time

Session replay is a discovery tool more than a reporting tool. When you find a bug in a replay, you still need to write a normal bug report — with the replay link attached as one piece of evidence.

Mobile crash logs

For mobile apps, the crash log is the most valuable single attachment. It contains the stack trace from the moment the app stopped.

iOS: Settings → Privacy & Security → Analytics & Improvements → Analytics Data, then find the file with your app's name
Android: adb logcat from a connected computer, or the crash entry in your error tracking tool

Attach the log file itself, and paste the top few lines of the stack trace into the report so it is searchable.

How much is too much

A useful rule: two types of evidence for most bugs, three for anything serious.

Severity	Attach
Trivial or minor	One annotated screenshot
Major	Screenshot + console log, or video + console log
Critical	Screenshot or video + console + network log + timestamp

Attaching everything for every bug is its own problem. Ten attachments on a small ticket makes the reader unsure which one matters. Always name the important one in the text.

The practical problem

Everything above assumes you had DevTools open before the bug happened, that you remembered to tick "Preserve log", and that you had two spare minutes to save and sanitise a HAR file.

In practice, bugs happen while you are testing something else. By the time you think about evidence, the page has already reloaded and the console has cleared.

There are two realistic answers. The first is a habit: keep DevTools open in a docked panel all day while testing, with "Preserve log" on. It costs nothing and it makes evidence available whenever you need it.

The second is tooling. Bug reporting tools such as Crosscheck run continuously in the browser and keep a rolling record of console output, network requests, and environment details. When you report a bug, the last few minutes of evidence are already attached — including the part that happened before you realised there was a bug.

Frequently asked questions

Is a video always better than a screenshot? No. Videos are slower to watch, larger to store, and impossible to search. Use one only when the bug involves a sequence or timing.

Can I paste a screenshot straight into the ticket? Yes, and inline images are easier to read than attachments. Just make sure the image is also uploaded as a file if your tool strips pasted images later.

How do I share evidence that contains customer data? Do not put it in the ticket. Reference the record by ID, and share the sensitive part through whatever secure channel your company uses. Note in the ticket where it can be found.

What if the console is empty but the bug is clearly technical? That is meaningful information in itself, so write it down: "No console errors." It tells the developer the failure is silent, which points them towards the network layer or the server.

Are GIFs a good middle ground? They can be — a short GIF autoplays and loops, which suits small interaction bugs. But GIFs have no sound, poor quality, and large file sizes. For anything longer than about five seconds, use a video.