Recording a software bug for a support ticket
You’ve found a bug. Standup is in twenty minutes, and you want it on today’s list, not next sprint’s. Here’s what actually gets a bug prioritized, in the order it needs to happen.
Start recording before you reproduce it, not after
The instinct is to trigger the bug first, then start recording once you know it’s about to happen again. Don’t. Start recording from a clean state — the moment before anything relevant happens — so the recording shows the actual starting conditions, not just the failure. A developer who sees the setup can rule out causes faster than one who only sees the crash.
Show the expected behavior first, if you can
If there’s a working case you can demonstrate right before the broken one — the same action succeeding somewhere else, or working yesterday — showing that contrast in the same recording is worth ten sentences of written description. “Here’s it working on the staging environment, here’s it failing on production” tells a developer more in fifteen seconds than a paragraph would.
Narrate what you’re clicking, not just what you see
Silent recordings force a developer to reverse-engineer your mouse movements. A simple, continuous narration — “clicking submit now… waiting… and here’s the error” — removes that guesswork entirely, and it’s the single biggest difference between a recording that gets acted on immediately and one that sits in a queue with a “can you clarify what you clicked” comment.
Include the boring stuff: browser, OS, account state
Say your browser and version, your OS, and anything unusual about your account or environment (logged in as admin vs. regular user, specific feature flag enabled) out loud during the recording. This is the information developers ask for in a follow-up comment 90% of the time — including it up front skips that entire round-trip.
Keep it under three minutes
If reproducing the bug reliably takes longer than that, that’s useful information itself (intermittent bugs are a different triage category than reliably reproducible ones) — but don’t pad a three-minute reproduction into a rambling ten-minute recording. Developers deprioritize long, unfocused recordings before they even finish watching them.
What to do after recording
Attach the file directly to the ticket rather than a separate link that might expire or require extra permissions to access — friction between “developer opens ticket” and “developer sees your recording” is the last thing standing between your bug and getting picked up today instead of next sprint.
Frequently asked questions
What should I say out loud while recording a bug report?
Narrate every click and your expectation at each step — “clicking submit, expecting a confirmation message, instead getting this error” gives a developer everything they need without a follow-up question.
How long should a bug report recording be?
Under three minutes for most issues. If reproducing it reliably takes longer, that’s itself useful triage information — mention that the bug is intermittent rather than padding the recording.
Should I include my browser and OS information in the recording?
Yes — saying it out loud during the recording answers the most common developer follow-up question before it’s even asked.
Related reading: Documenting a software bug for a support ticket · Everything you need to know about screen recorders for customer support · How to record your screen without lag