A good bug report with video combines a short recording of the bug happening with a written summary, steps to reproduce, expected versus actual result, and environment details. The video proves the bug and shows timing; the text makes it searchable and repeatable. Below is a template you can paste into any tracker, plus guidance on what to record so the developer does not have to ask follow-up questions.
Why a bug report with video gets fixed faster
Most back-and-forth on a bug ticket comes from missing context: "Which page?", "What did you click first?", "What browser?", "Can you show me?" A recording answers several of those at once. The developer sees the exact path you took, how long things took, what was on screen right before the failure, and whether there was an error message that flashed and disappeared.
Video also catches details the reporter did not think were important. A double click instead of a single click, a filter left on from an earlier session, or a slow-loading spinner that you clicked through all show up in a recording, even when you would never think to write them down.
What video does not do on its own is explain why the bug happened. That is where written context and, ideally, network and console logs come in.
The bug report template
Copy this structure into Jira, Linear, GitHub Issues or whatever tracker your team uses. Each field has a job.
- Title: what broke, where, and under what condition. "Checkout total ignores discount code when cart has 2+ items" beats "Checkout broken".
- Summary: one or two sentences in plain language. What you were trying to do and what went wrong.
- Steps to reproduce: numbered, one action per step, starting from a known state (logged out, fresh page, specific account).
- Expected result: what should have happened.
- Actual result: what did happen, including any exact error text.
- Video: the recording, with a timestamp for the moment the bug occurs (for example "bug at 0:23").
- Logs: console errors and network requests from the same session, if you have them.
- Environment: browser and version, OS, device, account or role, app version or URL, feature flags.
- Frequency: always, sometimes (for example 3 out of 10 tries), or once.
- Severity or impact: who is affected and whether there is a workaround.
For steps to reproduce, write one action per line and include the boring parts: which account, which page you started on, and what you typed. If you can only reproduce the bug some of the time, say so and say how many attempts it took.
What to record (and what to leave out)
The best bug videos are short and boring in a good way: they show the minimum path to the failure and nothing else.
Before you hit record
- Reset to a clean starting point: reload the page, log in as the test account, close unrelated tabs.
- Close anything sensitive. Personal email, customer data and API dashboards should not be visible. See how to hide sensitive information in screen recordings.
- Decide what to capture: a single browser tab is usually enough for web app bugs and keeps the recording focused. See how to record a Chrome tab.
While recording
- Move deliberately. Pause briefly before each click so viewers can see where the cursor is going.
- If you use a microphone, narrate what you expect: "I'm applying the code, the total should drop to 40."
- Let the failure sit on screen for two or three seconds before stopping so error messages are readable.
- If the bug is intermittent, keep recording through multiple attempts rather than starting and stopping.
After recording
- Trim dead time at the start and end.
- Note the timestamp where the bug happens and put it in the report.
- Export at a size your tracker accepts. MP4 is the safest choice for playback everywhere.
Add logs so the video explains itself
A video shows the symptom. Logs show the cause. If a button does nothing, the recording tells you the click happened, but only the network panel tells you the request returned a 500, and only the console tells you a JavaScript error was thrown.
You can collect these manually with Chrome DevTools: open the Network and Console panels before you reproduce, then export a HAR file and save the console output. The catch is that you need to remember to open DevTools first, and the logs end up in separate files with no link to the video timeline. A screen recorder that captures network requests solves both problems by logging everything during the take.
One caution: HAR files and copied requests can contain cookies, auth headers and tokens. Review them before attaching to a ticket that many people can read.
Recording a bug report with Click & Record
Click & Record is a free Chrome extension that was built partly for this job. When you record a tab, you can turn on network and console capture. Every request and console line is timestamped against the video, and clicking a row in the editor seeks the video to that moment, so a developer can jump straight from "POST /api/cart 500" to what was on screen when it fired.
From the same take you can export a standard HAR 1.2 file that opens in Chrome DevTools, or use "Copy as cURL" on a single request so the developer can replay it in a terminal. Capture does not use the Chrome debugger API, so there is no "is debugging this browser" banner and DevTools stays available if you want it.
Clicks are also logged and turned into automatic zooms after recording, which helps on high-resolution screens where a small dropdown would otherwise be unreadable. Each zoom can be adjusted or deleted in the editor. Everything runs locally; nothing is uploaded unless you choose Save to Google Drive.
Bug report checklist
| Check | Why it matters |
|---|---|
| Title names the feature and the condition | Makes duplicates easy to spot |
| Steps start from a known state | Someone else can follow them cold |
| Expected and actual are both stated | Avoids "works as designed" confusion |
| Video is under about a minute, with a timestamp | Reviewers watch it immediately |
| Console and network logs attached and reviewed | Points to the cause, not just the symptom |
| Environment listed | Rules out browser or account differences |
| Frequency noted | Sets expectations for reproducing |
If the report comes from a customer rather than a teammate, the same principles apply with less jargon; see screen recordings for customer support.
Putting it together
A bug report with video works best when the recording and the text do different jobs: the video shows exactly what happened once, the written steps let anyone repeat it, and the logs explain why. Whatever tool you use, keep the recording short, start from a clean state, and timestamp the failure. If you want the video, the network requests and the console output to come from one take and line up automatically, Click & Record does that for free, with no account.
Frequently asked questions
Should a bug report have a video or a screenshot?
Use a screenshot when the problem is a static visual defect, like a misaligned button. Use a video when the bug depends on a sequence of actions, timing, or something that changes on screen.
How long should a bug report video be?
As a rule of thumb, aim for under a minute. Start a few seconds before the first relevant action and stop right after the bug appears, then trim anything in between that does not matter.
Does a video replace written steps to reproduce?
No. The video shows what happened once, while written steps let someone repeat it and let people search the tracker later. Include both.
What should I do if the bug only happens sometimes?
Record every attempt until it happens, note how many tries it took, and capture network and console logs during the recording so the failing attempt carries technical evidence.