# Show someone a bug in an app running on your computer — Rill

Source: https://userill.dev/blog/record-localhost-bug-share-evidence

You click Cancel, reopen the form, and the changes are still there. You want someone else to take a look, but the app only runs on your computer.

Sending them http://localhost:3000 won’t open your app for them. “Localhost” points to the computer opening the address, so their browser will look on their own machine.

A short recording lets them see what happened on yours. Here’s how to capture the problem with Rill and give them enough context to help.

## Record the steps that show the problem

Open the page where the bug happens. Start close to the problem so your teammate can get to the relevant moment quickly.

Use sample data and a test account. Check for private information before recording. Saved recordings upload to Rill, and Rill does not hide sensitive information in the video.

Choose how to record:

*   [Record your screen](https://userill.dev/record) if you want to do the steps yourself. Choose the window or tab, repeat the steps, and preview the recording before saving. You can add narration to explain what you expected.
*   [Ask your coding agent to record](https://userill.dev/docs/agent-quickstart) if it has supported browser tools. Your agent does the steps while Rill records the run. Check that its browser can open your local app first.

## Tell your agent what to try

Give it a specific action and an expected result. Here’s a fictional example using a project named Cedar; it isn’t a recording we’ve tested.

You change the project name to Cedar draft and click Cancel. When you reopen the edit panel, you expect the original name, Cedar, to appear.

You could ask:

> Follow https://userill.dev/docs/agent-quickstart. Open http://localhost:3000 and record these steps in the test project Cedar: rename it to Cedar draft, click Cancel, then reopen the edit panel. Expected result: the name is Cedar. Don’t save the edit or change the app. Ask me if you’re stuck. Send the recording link and its expiry.

Replace the address, project name and steps with your own. Keep the recording focused on the problem you want someone to investigate.

## Watch it before you send it

Play the finished recording. Make sure it shows the starting point, the action and the unexpected result. If a new tab or popup opens, check that the relevant part is visible too.

In the Cedar example, your teammate needs to see you click Cancel and reopen the panel with the changed name still showing.

Describe what you can see. The recording shows the name reappearing; someone still needs to investigate why it happens.

## Add a short explanation beside the link

Share the recording where you’re already discussing the bug. Say what happened, what you expected and where to look. Mention the app version if you have one so your teammate can check the same one.

For the fictional example:

> After I click Cancel and reopen Cedar’s edit panel, it still shows Cedar draft. I expected it to show Cedar. Please watch the end of this recording: \[link\]. I’m using \[app version\]. The link expires \[date\].

Review the recording before copying the link. Anyone with an active share link can watch it and see any included browser details. A link in a private conversation can still be forwarded. Check the recording’s access and expiry; [sharing details](https://userill.dev/docs#capture-details) explain the defaults.

## Repeat the steps after the fix

When the app is updated, try the same steps with the same test data. For Cedar, check that reopening the panel after Cancel shows the original name.

Share the new recording alongside the first one so your teammate can see the change. Say which steps you checked and anything that still needs a look.

[Record your screen](https://userill.dev/record) or [set up agent recording](https://userill.dev/docs/agent-quickstart).