← All playbooks
Tier 4: Total Clusterfuck

What do you say after shipping a bug that caused real damage?

The short answer

Stop the bleeding first — roll back or feature-flag before you write anything. Then post a factual update with the timeline in UTC, the measurable impact, what's already contained, and what's next with an owner and a time. Blameless framing is not a favor to you; it's what keeps people reporting problems early next time.

What's actually at stake

  • 01Every minute you spend drafting instead of mitigating shows up in the impact number.
  • 02Executives read the impact line and the ETA. Everything else is for the retro.
  • 03Naming yourself as the cause before someone else does converts a scandal into an incident.

Do

  • · Mitigate first, communicate second, explain third.
  • · Give a numeric impact estimate with confidence bounds.
  • · Schedule the postmortem in the same message.

Don't

  • · Do not speculate on root cause in the first update.
  • · Do not use passive voice to hide who deployed.
  • · Do not promise 'this will never happen again'.

A draft you can send now

Status: [feature] was broken from [start] to [end] UTC, affecting approx [N] users / $[X]. Rollback is complete and metrics are recovering. I deployed the change. Full postmortem scheduled for [date] — I'll own it.
Tailor this to my exact disaster →

Questions people actually ask

Should I say it was my code?
Yes. Everyone can read the commit history. Volunteering it is the only version that helps you.
How precise does the impact number need to be?
Precise enough to act on, with the uncertainty stated. 'Between 2k and 4k orders' beats silence.
What if the review process failed too?
That belongs in the postmortem, not in the incident update. Order matters.

Take it further

Related incidents

All CYABot tools →