Video bug reports: how to record a bug developers can fix

A thirty second recording can settle a "cannot reproduce" thread that has run for a week, if it shows the failure quickly and says what was supposed to happen.

By the VeoRec team · Oct 3, 2026 · 12 min read

Some bugs are easy to write down. "The VAT number field is empty after the second save" needs no film. Others fall apart in text: the dropdown that closes itself if you move the mouse too fast, the button that submits twice when the network is slow, the modal that flickers for one frame. That is where video bug reports earn their place. A recording shows the order of events, the timing and the small detail you did not think to mention.

But a recording can also be three minutes of someone hunting for the right page while the developer scrubs back and forth looking for the problem. This guide covers when a video is worth it, how to set up before you press record, what to show in the first ten seconds, and how to keep passwords and customer data out of the shot.

Why a recording catches what a written report misses

Simon Tatham's essay How to Report Bugs Effectively makes a simple point that holds up decades later: the best bug report is to show the programmer the failure yourself. They watch what you do, and they notice things you would never write down because you did not know they mattered. A recording is the closest you can get to that when the developer is in another time zone.

A recording also carries context for free. The URL bar shows the environment. The header shows which account you are signed in as. The pace of your clicks shows whether you double-clicked or waited. Each of those can be the clue that makes a bug reproducible, and each is easy to leave out of a written report.

What a recording does not do is replace the text. The VS Code team's guide to submitting bugs says it plainly: images and animations illustrate the reproduction steps but do not replace them. Text can be searched, copied into a test case and checked line by line after the fix. Write the steps, then attach the video as proof and as a backup for any step that turns out to be ambiguous. If you need a refresher on the written part, see how to write a bug report.

Decide whether this bug needs a video at all

Not every bug deserves a recording. A typo, a wrong price or a broken layout is clearer as a screenshot, because the developer can see it at a glance in the ticket preview. Screenshot, GIF or video has the full decision guide; for a single bug, three questions sort it out:

Set up the screen before you press record

Thirty seconds of preparation saves the developer several minutes of squinting. Before you record:

• Get back to a clean starting point. Sign in fresh, empty the cart, open the page the steps begin on. If the bug needs setup data, create it before recording, not during.
• Record the tab, not the screen. Chrome's share dialog lets you pick a single tab, a window or the entire screen. A tab keeps your email, chat and other windows out of the video, and it keeps the frame the size of the page.
• Make it readable. If the text is small, zoom the browser to 110% or 125% before you start. A 1080p recording of a 4K screen with tiny text is a blurry recording.
• Silence notifications. Turn on Do Not Disturb so a chat preview does not slide across the frame in the middle of the reproduction.
• Open DevTools if it matters. If the bug produces a console error or a failing request, dock DevTools to the side of the tab before recording, so the error appears in the video at the moment it happens.

Decide too whether you need your camera. For a bug report the answer is usually no: the developer needs to see the page, and a face in the corner can cover the part that breaks. Voice is different. Narration is the most useful thing you can add, as the next sections show.

Show the problem in the first ten seconds

The developer opening your video wants one thing: to see the bug. Every second before it is a second they might skip past the clue. Plan the opening like this:

1. Frame (0 to 5 seconds) The page is already open with the URL visible. Say one sentence: "This is staging, signed in as an admin, on the billing page. Saving the address twice clears the VAT number."
2. Reproduce (5 to 30 seconds) Do the steps at normal speed, exactly as written in the ticket. Say each action as you do it: "Typing the VAT number, saving. Now changing address line two, saving again."
3. Show the failure and hold (a few seconds) When it breaks, stop moving. Point at it with the cursor and say what is wrong: "The VAT field is empty." Holding still gives the developer a clean frame to pause on.
4. Prove it (optional, 10 seconds) Reload the page, or open the record somewhere else, to show whether the change really reached the server. One check is enough.
5. Stop Do not narrate theories or apologise for the length. Stop the recording; put any theory in the ticket under a "Notes" heading.

If the steps take more than a minute to get through (a long checkout, a multi-page form), flip the order: show the broken result first in five seconds, then say "here is how I got there" and reproduce it. The developer knows what to look for before the long part begins.

To see why the opening matters, picture a typical first attempt: a two minute forty recording of a coupon bug. The first fifty seconds are the tester signing in and searching for a product. The next minute is the cart, with some commentary about a different, unrelated issue. The wrong total appears at 2:15, on screen for two seconds, while the narration is still about the cart. A developer who skims at double speed misses it.

The fixed version is forty seconds long. It opens on the cart with the product already in it, says "on this 100 euro cart, a 10% coupon and an 18 euro gift card should leave 72 euros to pay", applies both, and holds on the total, which reads 80. The unrelated issue gets its own ticket. Same bug, same tester, a quarter of the length, and nobody has to hunt for the moment it breaks.

Say what you expect before you click

A silent recording shows what happened. A narrated one also shows what you expected, and the bug lives in the gap between the two. The most useful habit is to say the expected result just before the click that should produce it: "When I click Save, the value should stay." Then click. If it does not stay, the developer hears the expectation and sees the actual result in the same second.

A few more narration habits that pay off:

• Read out values you type. "Entering D E one two three four" means the developer does not have to freeze the frame to read your input.
• Say what you are not doing. "I'm clicking once, not double-clicking" removes a whole line of questions on a duplicate submit bug.
• Name the build or flag if it is not visible. "This is the new checkout, flag on for this account."
• Keep it plain. No need for an intro or an outro. Talk the way you would if the developer were sitting next to you.

Your microphone does not need to be good, just close. A headset or the laptop mic in a quiet room is fine. If your voice echoes, move to a smaller room with a rug or curtains, or sit nearer the mic and speak a little more quietly.

Mark the moment it breaks

Even a short video benefits from a pointer to the right second. At minimum, write the timestamp in the ticket: "Recording, 1:10, bug at 0:42". Better still, mark it while you record so you do not have to scrub back afterwards to find it.

In VeoRec you press M (or use the toolbar) at the moment of failure; the marker becomes a chapter you name on the finish screen, such as "Second save clears VAT". Clicks are highlighted in the video, so the developer can see exactly what you clicked and when. Try it in the simulation below: add the lamp, press Save order twice, and drop a marker when the duplicate appears.

You can also draw on the screen while recording to circle the problem. That helps most for visual bugs, where "this gap here" needs a pointer more precise than a cursor. Keep drawings minimal: one circle around the broken element says more than a page of arrows.

Catch an intermittent bug on camera

Bugs that happen one time in ten are the ones that most need a video, and the hardest to get on one. You cannot plan a ten second clip around a failure you cannot trigger on demand. The trick is to reverse the approach: start recording, then repeat the steps until it fails, and drop a marker the moment it does.

The result is a longer video, but a precious one. It shows the attempts that worked next to the one that did not, and the differences between them are often the clue: a faster click, a page left open longer, a request that took a beat more to return. Note in the ticket how many attempts the recording contains and which one failed ("7 attempts, fails on the 5th at 3:12"). Check your recorder's length limit before a long session; on VeoRec's Free plan a recording can run up to 10 minutes, and up to 10 hours on Pro.

If the bug still refuses to show up on camera, the recording of the passing attempts is still useful. It proves the steps you wrote down are the steps you took, which narrows the search to the environment or timing.

Keep the video short and about one bug

The ideal bug video is as short as the reproduction. For most web app bugs that is between twenty seconds and a minute and a half. Longer is fine when the flow is long, but long videos need structure: chapter markers at each stage, so the developer can jump to "payment step" without scrubbing.

One bug per video follows the same logic as one bug per ticket. If you find a second problem while recording, finish the first, stop, and record the second separately. Two bugs in one video means one ticket links to a video where half the content is about something else, and whoever verifies the fix later has to remember which half matters. There is more on lengths by purpose in how long a work video should be.

If you recorded too much (a slow start, a wrong turn), trim it before sharing. Cutting the first twenty seconds of setup is the single edit that most improves a bug video, and it takes seconds in any editor that can trim.

Keep secrets and personal data out of the frame

A bug recording travels further than you expect. It gets linked from the ticket, pasted into a chat channel, attached to a vendor support request, and sometimes posted to a public issue tracker. Anything visible in the frame goes along with it: API keys on a settings page, a customer's email address in a table, your own inbox in another window, a password typed into a field in plain text.

The safest recording is one where there is nothing to hide. Use a test account with fake data, record only the tab, and close everything you would not show a stranger. When the bug only happens on real data (a specific customer's account, a production record), record it anyway, but treat the video as sensitive: keep it in the private ticket, and blur the personal details before sharing it more widely.

Run through this before you press record. Your ticks are remembered in this browser, so it works as a reusable pre-flight check:

If something slips through, fix it before you share. VeoRec's editor lets you draw blur boxes over parts of the frame and then render the video to apply them. For a full routine, from preparing the screen to access controls, see hiding sensitive information in screen recordings.

Record the bug, paste the link Record the tab where it happens with your voice and click highlights. The video uploads while you record, and the link is copied when you stop. See the bug reporting recorder

Attach a video bug report so it gets watched

How you put the video in the ticket decides whether anyone presses play. Two options, with different trade-offs:

• Upload the file to the tracker. It lives with the ticket forever, but trackers have size limits. GitHub, for example, accepts video uploads in .mp4, .mov and .webm, up to 10 MB on free plans and 100 MB on paid ones. A couple of minutes of high-resolution screen recording can exceed the lower limit.
• Paste a link. No size limit and nothing to export, but the video lives somewhere else, so make sure the people who need it can open it, and that it is not public when it should not be.

Either way, put three things next to the video in the ticket: its length, the timestamp of the failure, and one line on what to watch for. "1:10, bug at 0:42: VAT field empties after the second Save." A developer reading that line may not even need to press play, and if they do, they jump straight to 0:42.

If your recorder makes a transcript, it is worth a glance before you share. Spoken values like "D E one two three" become searchable text, which helps the next person who searches the tracker for that error.

Use the video for the conversation, not just the report

A recording works as a meeting point. Instead of describing which moment they mean, the developer can comment at the exact second: "at 0:38 the request fires twice, is that one click?" Timestamped comments keep the discussion attached to the evidence, rather than spread across chat threads where the next person will never find it.

When the fix lands, record the same steps again on the fixed build and attach that video to the ticket too. Two short recordings, before and after, are the clearest verification note there is, and they help months later when someone asks whether this ever worked. The QA to developer handoff checklist covers the rest of that loop, from triage to closing the ticket.

What to do next

Next time you find a bug that took you more than one sentence to describe, record it. Keep it under a minute, show the URL, say what you expect before the click, mark the failure and paste the link with the timestamp into the ticket. Then watch it once yourself at normal speed. If you can see the bug without reading the ticket, so can the developer.

If your team tests a lot, make recordings part of the routine rather than a special effort. The screen recorder for QA page shows how that looks with VeoRec.