X — fixed notice
Fixed: [short description of the bug]. Affected: [who, and since when]. Cause: [one-line cause, if you can share it]. Action needed: [none / refresh / update to version X]. Sorry for the trouble, and thanks to [@handle] for the report.
Bluesky — reply to reporters
The [bug] several of you reported is fixed in [version / as of time]. If you still see it, [clear step, e.g. clear cache], then reply here and we will look again.
Mastodon — technical detail
[Project] [version] fixes [bug description] ([issue link]). Cause: [technical cause]. Impact: [scope, e.g. only affected users on version X with setting Y]. Upgrade: [command]. Thanks to [@handle] for the reproduction steps. #[ProjectTag]
LinkedIn — customer-facing note
A quick update for [Product] customers. Between [start time] and [end time], [what users experienced]. It is now fixed. [Whether data was affected and what you checked.] What we are changing so it does not happen again: [specific change, e.g. added a test, new alert]. If you were affected and need help, contact [support channel].
Tips
- Say whether users need to do anything. It is the first question every affected user has.
- Thank the person who reported the bug by handle, with their permission; it encourages future reports.
- Keep the cause explanation honest and short. Detailed postmortems belong in a linked write-up.
- Reply directly under the original complaint posts too, so people who reported the bug see the fix.
Frequently asked questions
Should I announce every bug fix?
No. Announce fixes for bugs that were visible, widely reported, or affected data. Routine fixes belong in release notes or a changelog.
How fast should a fix announcement go out?
As soon as the fix is verified in production. Draft it while the fix deploys, then review and publish once you have confirmed it works.