What you need
A browser, DevTools, and a screen recorder. “It’s broken” is not a bug report, and neither is a paragraph describing what you saw: by the time a developer reads it, half the context is gone (which browser, which steps, what the console said) and you are both in for a round of “can you send a screenshot?”. A recording collapses that into one link.
Step by step
- Get to the page where it breaks. Open the exact URL and state where the problem happens, but do not trigger the bug yet. You want the reproduction on camera.
- Open DevTools with the console visible. Press F12 (or Ctrl+Shift+I / Cmd+Option+I) and leave the Console or Network tab open on screen so any errors are captured as they fire.
- Start recording the whole screen. Click the Opivv icon (or press Alt+Shift+R) and choose Entire screen or the window, so both the page and DevTools are in frame. Turn your microphone on.
- Narrate expected vs actual, then reproduce it. Say what you expect to happen, then do the exact steps that break it. Talking through it as you click is what turns a video into a reproduction.
- Stop and paste the link into the ticket. Click stop and the share link is copied to your clipboard. Drop it straight into Jira, Linear, GitHub, or Slack, no file upload needed.
Show the console, not just the page
Record with DevTools open. The red error in the Console, or the failed request in the Network tab, is usually the actual fix, and it is the first thing the developer will ask for anyway. A recording of the page alone shows the symptom; a recording with the console shows the cause.
If the bug involves a request, click the failed one in the Network tab while recording so its status and response are on screen.
Narrate expected vs actual
Talk as you go: “I clicked Save, I expected the dialog to close, but it spun forever.” That one sentence, expected versus actual, is the difference between a reproducible bug and a guessing game. It also tells the developer when to start paying attention.
Include the boring details
Say the URL, the browser and version, whether you are signed in, and which account or environment you are on. These feel obvious to you and are invisible to the person fixing it. Ten seconds of context saves an hour of “works on my machine”.
Recording the entire screen rather than a single tab helps here, since the address bar, browser chrome, and any other windows involved are all captured.
Keep it short and reproducible
One bug per recording, and get to the reproduction fast. A 40-second clip that reproduces the issue cleanly gets actioned; a five-minute ramble gets left in the backlog. If the repro needs several attempts, re-record rather than making the developer watch you fumble.
Common questions
How do I record a bug report?
Open the page where it breaks with DevTools showing the Console, start a screen recording of the whole screen with your mic on, say what you expect to happen, then reproduce the bug. Stop, and paste the share link into the ticket.
Should I include the browser console?
Yes. The console error or the failed network request is usually the actual cause, and it is the first thing a developer asks for. Recording with DevTools open saves an entire round trip.
What details should I mention out loud?
The URL, your browser and version, whether you are signed in, and which environment or account you are using. Also state what you expected versus what actually happened.
Can I attach it to Jira, Linear, or GitHub?
Yes. You get a link rather than a file, so you paste it into the ticket or the pull request. Anyone can open it in their browser with no account and nothing to install, and there is no attachment size limit to worry about.
Is it free?
Yes. Opivv records and gives you a share link for free, up to 5 minutes per clip, which covers almost any bug reproduction. Pro ($5/month) adds longer recordings, AI transcripts, and password-protected links.
Related: Why recorded bug reports get fixed faster · Opivv for bug reports · Record a single browser tab