# How to tell a user the bug they reported is fixed

> Tell the reporter when the bug is fixed by moving the feedback item to done, then sending a short personal reply from your own email that names the fix. Ask them to confirm only when you could not reproduce the bug or the fix depends on their data or setup.

Source: https://escutaproduto.com/resources/tell-reporter-bug-fixed
Last updated: 2026-10-11

## Why telling the reporter matters more than the fix itself

Most people who report a bug never hear back. They see no acknowledgement, the bug goes away in a later release, and they never learn that their report was the reason. That silence costs more trust than the bug did. A reporter who hears "this is fixed, here is what changed" becomes the most loyal person in your user base, because they saw their feedback turn into a result.

The message does not need to be long. It needs to be accurate, specific and sent by a person. The status change in your inbox does not reach the reporter on its own, so the reply is a separate step that you control.

## How do you track the bug through statuses?

Escuta Produto gives each feedback item one of five statuses: new, planned, in progress, done or closed. Use them in order. A bug starts as new when it arrives. Move it to planned when you accept it into the queue, and to in progress when someone starts the work. Set it to done when the fix is live in production, not when the pull request merges. Use closed for reports you will not fix, with a note that says why.

Each item also has private internal notes. Write the commit or release version in the note when you move the status to done. Six months later, when the same bug returns, the note tells you what changed and where to look.

```text
new        arrived from the widget, reproduced: no
planned    reproduced, scheduled for the next release
in progress  branch open, cause found in the cart total logic
done       shipped in 2.14.3, note added with the commit link
closed     duplicate of report from last week, linked in notes
```

If you use an AI assistant connected to your inbox through the MCP server, the owner can change statuses and add notes from there. Still, read each report yourself before you mark it done. An assistant can move a status, but it cannot tell whether the reporter's problem is really gone.

## What should the reply say?

Keep the reply to four short parts: what the bug was, what changed, what the person should do now, and a thank you that names the report. Do not write a template that sounds like it came from a support team. Write it as a person who read the report and fixed it.

Here is an example for a checkout error:

"Hi Ana, you reported that the discount code disappeared after you changed the shipping address. We found the cause and fixed it in the release that went out this morning. You do not need to do anything, and the code should stay applied now. Thanks for the detailed message, it helped us find it fast."

Name the thing they reported in their own words. Avoid the word "unfortunately" and avoid apologizing three times. One clear apology is enough when the bug caused a real loss.

## Where does the reply go, if you have no email?

Escuta Produto does not send automatic emails to customers. The reply goes out from your own address, which means you can only reply if you have the reporter's email. The widget gives you one in two cases: the person typed it into the email field, or your app identified them with an email before the form opened. Anonymous reports from the hosted page or a logged-out visitor do not include an email unless one was typed.

If there is no email, you cannot reply directly, so do not invent a way to contact them. Mark the item done, and let the change speak for itself in your release notes. The [guide to writing a changelog](/resources/write-a-changelog) covers how to name fixed bugs so the public sees them too.

## When should you ask the reporter to confirm the fix?

Most fixes do not need confirmation. Ask only in three cases. First, when you could not reproduce the bug, so the fix is a best guess. Second, when the bug depended on the person's data, such as a long file name or a specific currency, and you cannot test their exact setup. Third, when the bug involved a loss of work, so a wrong fix would cost them again.

In those cases, write the reply so the confirmation is one step: "We changed how file names are saved, and the upload should work now. Could you try the same file again and tell us if it still fails?" Give them a single action and a single answer to give. Do not ask for a rating or a long survey.

If they do not reply within a couple of weeks, leave the item done. A silent reporter is not a failed fix. Add a note that you asked, so the next person reading the item knows the check was made.

## Batching replies after a release

After each release, filter the inbox to the done items from that version. Read the notes, then send one personal reply per person. Keep each reply specific. A batch of ten short replies takes less time than a single announcement that everyone skims. The [guide to following up on bug reports](/resources/follow-up-on-bug-reports) describes the timing, and the [status workflow article](/resources/feedback-status-workflow) explains how to run the statuses across a small team.

If several reports describe the same bug, reply to each reporter. Link them in the internal notes so you can count how many people were affected, and say so in the reply if the number is meaningful: "several people hit this, and it is fixed for all of you."

## Doing the status and reply cycle in Escuta Produto

Create a product for the app that has the bug, and make sure the widget sends the email field for logged-in users. The [widget docs](/docs/widget) explain the identify call that fills the email for signed-in customers. Use the notification webhook to see new reports in Slack or Discord, then move each one through the statuses as you work.

Read the [we-fixed-it message guide](/resources/we-fixed-it-message) for a reply pattern you can adapt. The point of the whole cycle is simple: the reporter should know, within a day of the fix, that their report changed something.

## Frequently asked questions

### When should you tell a user their reported bug is fixed?

Tell them after the fix is live in production, not when the code merges. Move the feedback item to done with the release version in an internal note, then send a short reply from your own email that describes what changed.

### Should you ask the reporter to confirm a bug fix?

Ask only when you could not reproduce the bug, when it depended on their data or setup, or when it caused a loss of work. Give them one action to take and one answer to give, and do not send a long survey.

### What if the reporter did not leave an email address?

You cannot reply directly, because Escuta Produto does not send emails to customers for you. Mark the item done and mention the fix in your release notes, so the change still reaches people who reported it anonymously.