Lead with impact and current status
Explain what customers or internal users cannot do, when the issue was first observed, and what is known about its scope. Distinguish measured impact from a preliminary estimate. If the affected population is still unknown, say that rather than copying a number from an unverified report.
Then state the current condition. A mitigation in progress is not a completed recovery. A normal error rate on one dashboard may not prove that delayed work has caught up. Choose words that match the evidence the team has actually checked.
Separate facts, hypotheses and unknowns
“Errors began after the deployment” is a timing observation. “The deployment caused the errors” is a causal claim. You may have good reason to investigate that hypothesis, but do not collapse those statements into one until the evidence supports it.
Use clear labels: confirmed, under investigation, not yet known. These labels let stakeholders judge what they can repeat. They also make it easier to update your understanding without appearing to contradict a previous certainty you never actually had.
Explain the action without narrating the investigation
Name the current mitigation or investigation step and its purpose. Customers usually need to know whether they should retry, wait, or use a supported workaround. Engineering leadership may also need to know which team owns the response and whether additional support is needed.
Keep internal debugging details out of a broad update unless they affect a decision. Avoid assigning blame while the incident is unfolding. The later review can examine contributing conditions carefully without turning the live channel into an argument about responsibility.
Promise the next update, not an unsupported recovery time
If you do not have a reliable estimate, commit to when you will communicate again. A team can give an update at 14:30 even if the root cause remains unknown. State what evidence you expect to collect before then and what would change the current plan.
After mitigation, say what has recovered and what is still being checked. A follow-up should distinguish the trigger from systemic causes, identify customer recovery work, and name practical improvements. Do not convert the post-incident message into a guarantee that the failure can never happen again.
Keep the decision in the explanation.
- Impact: who is affected and what cannot be done?
- Status: ongoing, mitigated, recovering, or verified restored?
- Known facts: what has been confirmed?
- Unknowns: what is still being investigated?
- Actions: mitigation, owner, and useful customer guidance.
- Next update: when stakeholders will hear more.
Same situation. Clearer explanation.
The release broke checkout. We are rolling it back and everything should be fixed in ten minutes. It looks like the database team's change.
Some checkout requests have been failing since 14:05. We have confirmed failures on card payments; the full customer impact is still being measured. The on-call team is rolling back the latest deployment while checking whether it explains the errors. We do not yet have a reliable recovery time. The next update will be at 14:30, even if the investigation is still ongoing.
Illustrative examples. Adapt the facts and commitments to your situation.
Common mistakes to catch
- Stating a suspected root cause as a fact.
- Giving an optimistic fix time without supporting evidence.
- Declaring full recovery before verifying customer-facing behavior.
- Skipping the next update because there is no new conclusion.
Now try saying it out loud.
Use the framework for one attempt. Listen back, choose one improvement, and try again.
Practice this conversationA couple of useful questions
What should I say when nothing has changed?
Restate the current impact, the active investigation or mitigation, and the next update time. A brief confirmation that the response is active is more useful than silence.
Should a customer update include the technical root cause?
Include it when verified and relevant, at a level the audience can use. During an active incident, impact and actionable guidance generally come before implementation detail.