Tell users their bug is fixed after you have checked the fix, on the channel they used, in words that match what they reported. Do not tell them earlier. A "fixed" message that turns out to be wrong costs more trust than silence. A reply that says "fixed" before anyone checked is a rumor with a signature.

Why reply at all

A user who reports a bug and hears nothing assumes nobody read it. A short reply shows the report mattered, and it brings the user back if the bug returns.

Check first

Re-run the step that failed, on the build that is live or on staging. Confirm that the fixed build is the one deployed. Watch for the same error for a set period. A merged pull request or a ticket marked Done proves that work was finished, not that the bug is gone.

Use the channel they used

If the user wrote in Slack, answer in the thread. If they wrote by email, answer on the same thread. If they wrote inside the app, answer there. A reply on another channel feels like a different company answering.

What to say

Say what they reported, what changed and what to do if it returns. Two or three sentences are enough. "We reproduced the duplicate download. It is fixed and checked on staging. Tell us if you see it again." beats a paragraph of apology.

When to say nothing

If a check fails, nobody is told the bug is fixed. If the cause could not be found, say what you know and what you are still checking, or wait. If the bug comes back after the Case closed, re-open it and keep the earlier outcome on the Case.

How SylvieSI handles it

After the checks pass and an Owner or Admin confirms, the Communication agent drafts an update for each person who reported the bug. A person, or your reply policy, sends it on the channel each person used. A message counts as sent when Slack, Gmail or your app confirms it.

Related articles

About the product ↗How it works ↗More from the Journal ↗