Screen recorder for bug reports: what to capture, and in what order

How to record a bug report video: the 60-second order

Reproduce the bug once without recording so you know the path. Then switch to a demo account, close chat and mail so no notification lands in the frame, and record one continuous take in this order.

1. 0:00–0:05 · Context. Say the build and environment aloud: “Build 4.12.0, staging, admin account.”
2. 0:05–0:15 · Starting state. Show the screen before anything goes wrong, including the URL or the window title.
3. 0:15–0:40 · Steps. Perform each action at normal speed and name it as you do it: “I type a name, I pick a role, I click Save.”
4. 0:40–0:50 · Failure. Stop moving the cursor and hold the wrong result on screen for three seconds.
5. 0:50–1:00 · Expected. Say in one sentence what should have happened. If the bug reproduces every time, trigger it a second time.

Bug report template to paste next to the video

The video is the evidence. The issue text is what gets searched, triaged, and linked from the fix. Copy these fields into the issue and fill in every line.

• Title: [Screen or feature] + [action] + [wrong result]. Example: “Invite form: Save clears all fields when role is Viewer.”
• Environment: app build, OS version, browser and version, account type or role.
• Starting state: what must be true before step 1 (logged in as…, feature flag…, sample record…).
• Steps to reproduce: numbered, one action per line.
• Expected result: one sentence.
• Actual result: one sentence, plus the exact error text if there is one.
• Frequency: every time, or N out of 10 attempts.
• Video: file or link, with the timestamp of the failure (for example 0:42).
• Logs: console output or request ID, pasted as text.

Worked example: a form that clears itself on Save

The situation: on the staging build of a team-management app, saving an invite with the Viewer role wipes the form and sends nothing. It works for Editor. The video is 48 seconds long, and the failure is at 0:31. The issue text reads:

• Title: Invite form: Save clears all fields when role is Viewer.
• Environment: build 4.12.0 (staging), macOS 15.1, Chrome 129, workspace admin.
• Starting state: logged in as [email protected], Team → Members open, no pending invites.
• Steps: 1. Click Invite member. 2. Enter name “Sam Park” and email [email protected]. 3. Set Role to Viewer. 4. Click Save.
• Expected: the invite appears under Pending with the Viewer role.
• Actual: the form empties, no toast appears, and Pending stays at 0. No error on screen.
• Frequency: 5 out of 5 with Viewer, 0 out of 5 with Editor.
• Video: invite-viewer-bug.mp4, failure at 0:31. Second reproduction at 0:40.
• Logs: POST /invites returns 422, “role: unsupported value”.

Video, screenshot, or written steps: which one to file

Pick the format by what the developer needs to see. Most good reports combine two: written steps plus either a video or a screenshot.

Recording audio bugs and rare failures on a Mac with Qreata

Audio bugs are where a general-purpose recorder lets you down. Say your app plays its notification sound twice. Qreata always captures system audio together with the screen, on its own track next to the microphone track, so there is nothing to switch on and nothing to forget. Before export you can mute the microphone track or lower its volume, so the developer hears the doubled sound without your keyboard and voice on top of it.

For a bug that appears once a day, the worry is losing the take. Qreata writes the recording to disk in five-second chunks with a recovery journal, so if the session is interrupted, the part already saved is restored the next time you open the app. Before you start, the Active source check shows live frames and audio for each source.

If the bug is in one small window, choose Window as the capture target, not Display, so the text stays readable in the tracker’s player. After recording you can enlarge the cursor and highlight clicks, which shows the developer exactly where you clicked.

Keep the failure itself untouched. If you misnamed the build in the first five seconds, Shift-drag across 0:00–0:06 on the timeline with Replace Take (the tool is labelled Rerecord in the editor) and re-record that line only, filling the full six seconds. The footage of the bug at 0:31 stays exactly as captured.

The recording stays on your Mac unless you press an upload button, and you do not need an account to record. A demo account is still the first choice, but some bugs reproduce only in a real one. For those, turn on Blur · select elements before the take and click the elements to hide, up to 8, such as an email column: the blur follows them as the page scrolls. It needs the macOS Accessibility permission and stays in the recording for good. For something you notice later, the Blur tool in the editor covers a fixed rectangle for a time range. To try it, use the 7-day trial on a bug you already filed: record it in the order above and compare the result with your original report. It takes about ten minutes.

Common mistakes that get a bug video sent back

These are the reasons a developer replies “can’t reproduce” to a report that has a video attached.

• Starting mid-flow. The video opens on the error, and nobody can tell how you got there.
• Trimming the steps. Cutting the “boring” 20 seconds before the failure removes the reproduction.
• No build number. The bug may already be fixed in a newer build.
• A five-minute recording with the failure at 4:10 and no timestamp in the issue.
• Re-enacting an intermittent bug and filing the re-enactment as the original event.
• Recording the whole 4K display when the bug is in one small window, so the text is unreadable in the tracker’s player.
• A video with no written steps. Nobody can search for it later.