How to Communicate During an Incident
Author: Ksenia Izotova
Last updated: September 2026
Last updated: September 2026
What should an incident update include?
An incident update should state the time, user impact, confirmed facts, current actions, owners and the next communication point. Keep suspected causes separate from evidence. Use one channel or record as the agreed source of truth, and make roles visible so responders know who is coordinating, investigating and communicating. External updates usually need less technical detail than the responder channel, but they still need a clear description of impact and what affected users should do. If there is no recovery estimate, give the time of the next update.
The person fixing the service and the person answering every question do not always need to be the same person. During a larger incident, that arrangement quickly becomes expensive.
The person fixing the service and the person answering every question do not always need to be the same person. During a larger incident, that arrangement quickly becomes expensive.
The examples are illustrative. Follow your organisation’s incident process, security rules and approval path for external communication.
Declare the incident and make the roles visible
Google’s SRE guidance describes structured incident response with a clear line of command, defined roles, a working record and early declaration. It distinguishes the Incident Commander, Operations Lead and Communications Lead. Source: Google SRE Workbook, Incident Response
Your team may use other names. The language still needs to show who is doing what.
“SEV-1 declared at 14:08 UTC. Priya is Incident Commander. Tomas owns mitigation. Lena will post stakeholder updates every 30 minutes.”
This message removes three common questions: Is this being managed as an incident? Who can make a decision? When will we hear more?
Avoid assigning five people to “investigate” without an owner or a reporting point. Parallel work helps only when the results return to the same coordination process.
Your team may use other names. The language still needs to show who is doing what.
“SEV-1 declared at 14:08 UTC. Priya is Incident Commander. Tomas owns mitigation. Lena will post stakeholder updates every 30 minutes.”
This message removes three common questions: Is this being managed as an incident? Who can make a decision? When will we hear more?
Avoid assigning five people to “investigate” without an owner or a reporting point. Parallel work helps only when the results return to the same coordination process.
Write the first update before you know the cause
The first useful update can be short:
“14:08 UTC. Users in the EU region are receiving errors when creating new projects. Existing projects remain available. The incident started no later than 13:52 UTC. We are checking the API and database paths. No cause is confirmed. Next update by 14:30 UTC.”
It contains:
“14:08 UTC. Users in the EU region are receiving errors when creating new projects. Existing projects remain available. The incident started no later than 13:52 UTC. We are checking the API and database paths. No cause is confirmed. Next update by 14:30 UTC.”
It contains:
- the timestamp;
- affected users and action;
- an unaffected area;
- the earliest confirmed start time;
- the current investigation;
- the status of the cause;
- the next update.
You do not need to fill the gap with a theory. A clear boundary around what is known is useful information.
Four phrases that create confusion
“We have a huge problem”
Risk: “Huge” does not define scope or impact. It may increase anxiety without helping anyone act.
Clearer version:
“New project creation is failing in the EU region. Existing projects and other regions are operating normally.”
Clearer version:
“New project creation is failing in the EU region. Existing projects and other regions are operating normally.”
“The deployment broke the database”
Risk: This presents a timeline or correlation as a confirmed cause.
Clearer version:
“Errors began six minutes after deployment 4.22. We are testing the deployment as one possible cause. The database team has not confirmed a database failure.”
Clearer version:
“Errors began six minutes after deployment 4.22. We are testing the deployment as one possible cause. The database team has not confirmed a database failure.”
“John is fixing it”
Risk: The team cannot see the action, expected checkpoint or whether John needs help.
Clearer version:
“John is rolling back the API release. He will report the result by 14:20 UTC. Maria is checking whether any writes need replaying.”
Clearer version:
“John is rolling back the API release. He will report the result by 14:20 UTC. Maria is checking whether any writes need replaying.”
“It should be back soon”
Risk: Stakeholders may hear a recovery commitment.
Clearer version:
“The rollback has started and normally takes about 12 minutes. We have not confirmed that it will restore service. Next update at 14:30 UTC.”
For more ways to qualify forecasts, see how to talk about delays and uncertainty in English.
Clearer version:
“The rollback has started and normally takes about 12 minutes. We have not confirmed that it will restore service. Next update at 14:30 UTC.”
For more ways to qualify forecasts, see how to talk about delays and uncertainty in English.
Separate confirmed facts, hypotheses and decisions
During an incident, these three statements do different jobs:
- → Confirmed fact“Requests to the EU write endpoint are returning HTTP 503.”
- → Hypothesis“The timing suggests a connection with the 13:46 deployment. We are comparing errors before and after that release.”
- → Decision“We are rolling back the deployment while the database team continues its checks.”
Labels help when the channel is moving quickly:- Confirmed
- Investigating
- Decision
- Result
They also make handovers easier. Someone joining later can see which ideas were tested and which actions were approved.
Keep debugging detail out of the status update
Responders may need stack traces, commands and competing theories. Executives, support teams and customers need a stable summary.
Use two connected records:
Use two connected records:
- A responder channel or document for technical work.
- An incident log or status thread for confirmed updates, decisions and timestamps.
Copying every debugging message into the status thread makes it harder to find the current position. Removing all technical context is also unhelpful. Include the component or workflow when it explains impact or the chosen action.
“We are shifting traffic away from the affected region” is useful.
“Pod 7f3 is in CrashLoopBackOff because the sidecar cannot mount…” may belong in the responder channel unless that detail changes a stakeholder decision.
“We are shifting traffic away from the affected region” is useful.
“Pod 7f3 is in CrashLoopBackOff because the sidecar cannot mount…” may belong in the responder channel unless that detail changes a stakeholder decision.
Give each update a stable structure
Use the same order for every update. Readers can scan for the field they need.
Communicate mitigation before root cause
Incident work often moves in two tracks: reduce the impact and understand the cause. Google’s SRE incident-response sequence puts impact assessment and mitigation before root-cause analysis. A team may restore service before it can explain every failure mechanism.
“Traffic has been shifted to the second region, and new project creation is working again. We are monitoring error rates. The underlying cause remains under investigation.”
Do not write “resolved” when the workaround is active but fragile. Terms such as mitigated, monitoring and resolved should follow your incident policy.
“Traffic has been shifted to the second region, and new project creation is working again. We are monitoring error rates. The underlying cause remains under investigation.”
Do not write “resolved” when the workaround is active but fragile. Terms such as mitigated, monitoring and resolved should follow your incident policy.
Write for customers without inventing certainty
An external message should help an affected customer recognise the issue and plan.
“Some customers in the EU region are unable to create new projects. Existing projects remain available. We are working to restore project creation and will post another update by 15:00 UTC.”
You may need legal, security or communications approval before sharing cause, geography or data impact. Follow that process. If the customer asks for technical detail, explain the problem in terms of impact, evidence and next steps.
Avoid:
“A minor issue is affecting a few users.”
Unless “minor” and “a few” are supported, the message can sound dismissive.
“Some customers in the EU region are unable to create new projects. Existing projects remain available. We are working to restore project creation and will post another update by 15:00 UTC.”
You may need legal, security or communications approval before sharing cause, geography or data impact. Follow that process. If the customer asks for technical detail, explain the problem in terms of impact, evidence and next steps.
Avoid:
“A minor issue is affecting a few users.”
Unless “minor” and “a few” are supported, the message can sound dismissive.
Make the handover explicit
An incident handover should name the current state, open risks and next decisions.
“Incident command transfers from Priya to Daniel at 16:00 UTC. The service is mitigated through a traffic shift. Error rates have been normal for 35 minutes. The cause is still under investigation. Daniel owns the decision to return traffic. Maria continues the data-integrity check and will report by 16:20.”
The incoming lead should confirm:
“I have the incident, current actions and update schedule.”
Silence after a handover message leaves ownership unclear.
“Incident command transfers from Priya to Daniel at 16:00 UTC. The service is mitigated through a traffic shift. Error rates have been normal for 35 minutes. The cause is still under investigation. Daniel owns the decision to return traffic. Maria continues the data-integrity check and will report by 16:20.”
The incoming lead should confirm:
“I have the incident, current actions and update schedule.”
Silence after a handover message leaves ownership unclear.
Close the incident carefully
A closing update needs more than “Fixed”.
“Resolved at 17:12 UTC. Project creation in the EU region is operating normally, and queued requests have been processed. We found no evidence of data loss in the completed checks. The team will review the incident and track follow-up actions separately.”
If checks are still running, say so. If some customers need to retry an action, include the instruction. Do not publish a root cause that has not passed the required review.
“Resolved at 17:12 UTC. Project creation in the EU region is operating normally, and queued requests have been processed. We found no evidence of data loss in the completed checks. The team will review the incident and track follow-up actions separately.”
If checks are still running, say so. If some customers need to retry an action, include the instruction. Do not publish a root cause that has not passed the required review.
A quick check before posting
- Is the timestamp and timezone visible?
- Does the impact describe users or workflows?
- Have you separated confirmed facts from hypotheses?
- Are current actions and owners named?
- Is the next update time explicit?
- Does the message avoid blame and unsupported reassurance?
- Is sensitive information appropriate for this channel?
- Can a person joining now understand the current state?
Frequently asked questions
How often should we post incident updates?
Follow the severity policy and the needs of the audience. Choose a realistic cadence and keep it. An update can say that the impact is unchanged and the investigation continues. Silence makes stakeholders create their own explanations.
Should incident messages use simple English?
Yes. Responders are reading under pressure, and many stakeholders will not share the same technical context. Short sentences, explicit subjects and timestamps reduce ambiguity.
Can I name the person who caused the incident?
Incident updates should describe system impact, actions and ownership of the response. A person’s name may be useful as the owner of an action. Assigning blame during an active incident distracts from mitigation and may be wrong.
What if there is no estimate for recovery?
Say that no reliable recovery estimate is available, explain the current action, and give the next update time. Do not replace missing information certainty with “soon”.
Practise before the next incident
Practise an incident in which the cause stays unclear and a stakeholder asks for a recovery time. UnifyHub’s programme for DevOps and SRE teams uses scenarios like this. Book a team assessment.
Author: Ksenia Izotova
Last updated: September 2026
Last updated: September 2026