How to report a bug with a screen recording

A useful bug recording lets the next person watch the failure you saw. They can see which button you clicked, how the page responded, and what was still wrong afterward.

Start with one short flow. Point to the moment that matters, add what the viewer couldn’t see, and after a fix record the same flow again.

Use this method with the issue tracker your team already uses. Record my screen is one way to capture the evidence.

Rill offers three routes: record it yourself (this guide), record an agent running the same steps, or let Rill run a check. Screen recordings capture video and optional microphone audio, without automatic console or network diagnostics. Supported agent and hosted-browser runs can capture those diagnostics.

Choose one failure to show

Before recording, finish this sentence: “When I do ___, I expect ___, but I see ___.”

For example: “When I clear the optional Company field and save a contact, I expect it to stay blank. After reloading, the old company name comes back.”

That sentence defines the flow worth capturing. A recording that stops immediately after the Save click would miss the result after reload. A long tour of every contact setting would make the relevant moment harder to find.

If several problems appear, keep track of them separately unless they belong to the same reproduction. Give each recording a specific title, such as “Clearing Company silently fails to save.”

Record from a state someone else can repeat

Use a test account and safe sample data. Establish the state needed to reproduce the issue before you start, and note any setup that won’t appear in the video.

For this example, you need an existing contact, permission to edit it, and a Company field containing a value. Creating a new contact or replacing one company name with another would exercise a different flow.

In Rill, sign in and choose Record my screen. Select a tab, window, or screen from the choices your browser offers. Optional narration can explain what you expect while you work. Manual recordings capture video and optional microphone audio; they don’t automatically collect console or network diagnostics.

Perform the steps at a pace the viewer can follow. Leave loading states and waits visible when they affect the reproduction. Stop after the outcome is clear, then preview the video before saving it to your workspace.

Show the failure and point to the relevant moments

Here’s a fictional contact-management example. Its application, test data, timestamps, and results are illustrative. There is no actual recording attached.

The contact begins with Display name “Morgan Lee” and Company “Cedar Studio.” In this example’s product requirements, Company is optional.

A useful recording would show this sequence:

• 00:00 — Open the existing contact and show the saved Company value
• 00:04 — Select Edit, then clear Company completely
• 00:12 — Click Save once
• 00:13 — The button returns from “Saving…” to “Save,” with no success or error message
• 00:18 — Reload the page
• 00:20 — Company displays “Cedar Studio” again

The viewer can now see the failed outcome. Add a note such as “At 00:20, the old Company value returns after reload; the expected value is blank.” In Rill, reviewers can pause on the relevant frame and pin a comment there. That keeps questions about a specific moment attached to the evidence.

Add the context that wasn’t visible: the staging build, browser version, editor role, and how the contact was prepared. If you repeat the test, record what you reset. “Failed in 3 of 3 attempts after reloading the same contact before each attempt” describes the observation more precisely than “always broken.”

Link a diagnostic event to its moment in the video

Suppose a coding agent records the same contact flow in a supported Chromium browser with Rill. This route can capture console, network, and timeline events alongside the video. Network bodies depend on capture settings.

The network view shows PATCH /api/contacts/42 returning HTTP 422 just after Save was clicked. If the response body was captured, it also contains “company must not be empty.”

Click an event’s timestamp in Rill’s timeline, console, or network view to pause the video at that moment. Copy share link creates a link that opens the relevant tab, highlights and scrolls to the entry, and pauses at the matching time.

Send that link with a short note: “This request returns 422 after I clear the optional Company field. At 00:20, the old value returns after reload.” The developer can inspect the request alongside the action that produced it.

Jump to first captured error pauses two seconds before the earliest console error, failed request, or HTTP response of 400 or higher; it is hidden when none was captured. The first captured error may be unrelated to the reported bug and does not establish a root cause.

The request could point toward request construction, server validation, or a mismatch with the product requirement. Keep those explanations labeled as hypotheses until checked.

If you have only a screen recording, share that. It still shows a visible failure and a flow to reproduce. Use the agent recording guide when you want to capture an agent-driven run.

Send the recording with a short handoff

Put the recording near the top of the report. A teammate should be able to watch the problem, find the relevant moment, and reproduce the starting conditions without another round of questions.

Use this compact template beside the video:

Recording: [Link and the timestamp to inspect]

Goal: [What the person was trying to do]

Expected and observed: [The expected outcome and what appeared instead]

Page and version: [URL or route, environment, and build or commit]

Starting state and test data: [Account role, existing record, relevant settings, and exact safe inputs]

Steps: [The actions needed to repeat the recorded flow]

Diagnostics (if any): [Captured console or network evidence, with its source; note any other attachments]

Scope: [Failures / attempts, known impact, and anything not checked]

Paste this under the recording link; keep Scope honest about what you didn’t test.

For the fictional example, the impact is that an editor cannot clear a contact’s company name. The report should say that only one contact and one editor account were tested. A failure there doesn’t establish how many users are affected.

Don’t guess at missing details. “Earlier builds not checked” is useful information. If someone else can reproduce the issue on another version, they can add that result to the same investigation.

Record the same flow after a fix

Keep the original recording. After a fix, use the same starting state, same inputs, and same actions on the new build or commit.

For our example, clear Company, click Save, and reload. The expected visible result is a successful save followed by a Company field that remains blank. A recording of the confirmation message alone would leave persistence after reload unchecked.

Share both recordings with their tested versions and a short account of what changed. If an agent performed the check, ask it to return what it checked, what it observed, and anything it couldn’t verify.

A successful reproduction check supports that specific result. Broader regression testing needs its own evidence. Likewise, a recording’s browser error count doesn’t determine whether the task passed or failed; compare the observed behavior with the expected outcome.

Review the capture before sharing

Watch the video and inspect any included diagnostics for information that shouldn’t be shared. Rill doesn’t mask sensitive content in the video, and diagnostic redaction is best-effort.

Treat Copy share link as a sharing action. For a private recording, it creates a seven-day share link. If an active share link already exists, it reuses that link without extending its expiry. Anyone holding the active link can view the recording and its included diagnostics.

Review the capture and its access settings before copying a link. The capture and sharing guide explains the differences between recording routes.

For your next bug report, record the failed flow, point to the moment that matters, and add the context needed to repeat it. Keep that evidence with the issue so the person fixing it can review what happened and show what changed.