During an incident, communicate impact, current status, confirmed facts, actions underway, and the exact time of the next update. Separate observations from hypotheses: 'Requests are failing in checkout' is a fact; 'the database failover caused it' may still be a hypothesis. In the postmortem, describe how the system and operating conditions made an action reasonable at the time, while still naming decisions, consequences, and owners. Blameless does not mean vague or consequence-free. It means learning without using individual shame as the explanation.
The alert is firing. Customers cannot complete checkout. Three people are debugging, six people are asking for updates, and every message you type feels obsolete before you press Send.
Incident communication has two jobs. During the event, it reduces uncertainty for responders and affected stakeholders without distracting the people doing recovery work. After the event, it creates a shared account that helps the organization learn and improve without turning one person's mistake into the entire explanation.
This guide gives you language for both moments. Adapt it to your organization's incident roles, severity definitions, regulatory duties, and communication policies. A template supports judgment; it does not replace your incident process.
During the Incident, Reduce Uncertainty — Not Anxiety
A good status update is not a stream of everything happening in the response channel. It is the smallest accurate picture that helps the audience understand impact, confidence, and what happens next.
For most audiences, answer these questions in order: Who or what is affected? What are they experiencing? What is the current status? What are responders doing? What is confirmed versus still being investigated? When is the next update?
Lead with user or business impact, not the component that paged. "Checkout requests are failing for some customers" is more useful to a broad stakeholder group than "the payments worker is throwing connection exceptions." Technical responders can receive the component detail in the incident channel.
Choose one communication owner when your process allows it. That person gathers verified information from the response lead and sends updates on schedule, protecting active responders from repeated one-off requests.
Every update should include the time of the next update. Predictability reassures stakeholders without requiring you to promise a resolution time.
Use the Impact → Status → Evidence → Action → Next Update Format
Impact: State the affected user journey, service, region, or internal operation. Quantify only when you have a reliable measure. If scope is still unknown, say "scope is being assessed."
Status: Use plain state language: investigating, identified, mitigating, monitoring, or resolved — or the terms defined by your organization. Do not say "resolved" merely because one graph improved; use the verification criteria your response process requires.
Evidence: Name the few observations that matter. Separate them from causal theories.
Action: Describe the mitigation or investigation underway without exposing sensitive details to an audience that should not receive them.
Next update: Give an exact time and time zone. "Within an hour" becomes ambiguous when messages are forwarded.
Impact: Since 14:12 UTC, some customers in the EU region have been unable to submit orders. Scope is still being measured. Status: Investigating. Evidence: Error rates rose after the 14:05 deployment; we have not confirmed that the deployment is causal. Action: The team has paused further deploys and is testing a rollback. Next update: 14:45 UTC, or sooner if impact changes materially.
Ready-to-Send Incident Update Templates
Initial acknowledgment: "We are investigating reports that [users/process] cannot [action]. The issue began at approximately [time, if known]; scope is [known scope / still being assessed]. Responders are [current action]. Next update: [exact time and zone]."
Investigation update: "Impact remains [impact]. We have confirmed [facts]. We are investigating [question or hypothesis] and have not yet confirmed [uncertain cause]. [Mitigation] is in progress. Next update: [time]."
Mitigation update: "Impact is [improving/unchanged], and [metric or observation] shows [evidence]. We applied [plain-language mitigation] at [time] and are monitoring [verification condition]. We have not yet declared resolution. Next update: [time]."
No material change: "No material change since [time]. Impact remains [impact]. The team has ruled out [useful eliminated theory] and is now [action]. Next update: [time]."
Resolution update: "Service was restored at [time], and [verification evidence] has remained healthy for [relevant observation period]. Total observed impact was [scope, if confirmed]. We will continue monitoring [risk]. A follow-up review is planned for [date or timing], and we will share the appropriate findings and actions through [channel/process]."
Do not copy a template into a public status page if it reveals exploitable technical detail, private customer information, or unconfirmed security conclusions. Use the approved audience and review path for your organization.
Keep Facts, Hypotheses, and Decisions Separate
Under pressure, a plausible theory quickly turns into "the cause" as messages are repeated. Prevent that by labeling the type of statement.
Observation: "Error rates increased at 14:12 UTC." This is something measured or directly seen.
Correlation: "The increase followed the 14:05 deployment." The timing matters, but it does not prove causation.
Hypothesis: "We suspect the new retry behavior is exhausting connections." This is a theory being tested.
Decision: "We are rolling back because it is the fastest reversible mitigation, even though the cause is not yet confirmed." This explains why an action is sensible under uncertainty.
When confidence changes, update the language. "We suspect" can become "we confirmed through X" — or "we ruled out after Y." This is not indecision. It is accurate reasoning made visible.
If you need to present this to a mixed audience, use the impact-first approach from how to explain technical work clearly.
Never use an unverified root-cause claim to make an update sound decisive. A clearly labeled hypothesis is more trustworthy — and easier to correct — than confident fiction.
Translate for the Audience Without Hiding Reality
Responders need precise technical state. Executives may need customer impact, business exposure, major choices, and recovery confidence. Support teams need approved language, affected workflows, workarounds, and where to send edge cases. Customers need a truthful account of their experience and what they should do next.
These are not four competing versions of the truth. They are different resolutions of the same verified picture. Keep the core facts consistent: start time, affected capability, scope, current state, and resolution status.
Avoid technical shorthand with non-technical audiences, but do not use simplification to minimize the event. "A small database hiccup" is inappropriate if customers lost access for an hour. Plain language can still be exact: "A database failover did not complete as designed, so account requests could not be processed."
For security, privacy, safety, contractual, or regulated incidents, use the relevant internal response and disclosure process. Do not improvise public attribution, impact, or assurances from a general communication template.
What a Useful Postmortem Should Explain
A postmortem should make the event easier to understand and similar failures less likely or less harmful. It is not an incident-channel transcript and not a performance review disguised as a technical document.
A practical structure includes:
Summary and impact: What happened, who or what was affected, and for how long, using validated data and clearly noting any remaining uncertainty.
Detection and response: How the incident was noticed, which signals helped or hindered, and how the response unfolded.
Timeline: Important technical events and decisions with consistent timestamps. Include what responders knew at the time, not only what became obvious later.
Contributing conditions: Technical, organizational, process, interface, and environmental factors that combined to produce or extend the event. Complex incidents may not have one useful "root cause."
What helped and what made response harder: Successful safeguards and response practices matter because you want to preserve them.
Actions and learnings: Concrete changes, owners, priorities, and follow-up. Separate immediate remediation from longer-term risk reduction.
Blameless Language That Still Names What Happened
Blameless does not mean removing people from the story or writing everything in passive voice. "The configuration was changed" hides a decision. "An engineer changed the configuration after the deployment guide indicated the old value; the system accepted it without validation" explains both the action and the conditions around it.
Replace judgments with observable behavior and context:
Blaming: "The on-call engineer carelessly restarted the primary." Useful: "The on-call engineer restarted the node identified as secondary in the dashboard. Replication lag had made that label stale, and the runbook did not include an independent role check."
Stops at human error: "The deployer entered the wrong region." Useful: "The deployment command defaulted to the production region, and the review output displayed the region below the fold. The entered command therefore applied to production without a separate confirmation."
Vague and evasive: "Communication could have been better." Useful: "The response lead did not know Support had received 47 related tickets because the incident channel and support escalation queue were not connected. We first incorporated that impact data 38 minutes after detection."
The useful question is: Given what the person saw, the tools and procedures available, and the pressures present, why did this action make sense at the time? Then ask what would make the safer action easier or the unsafe action harder next time.
Write with specific subjects and verbs. Blamelessness comes from examining context and safeguards, not from hiding agency behind 'was done' and 'mistakes were made.'
Accountability Means Owners and Follow-Through
A blameless review can still hold people accountable for follow-up, professional standards, and deliberate choices. What it rejects is individual shame as a substitute for improving the conditions that allowed the event.
Weak action item: "Be more careful during deployments." It has no owner, no verifiable end state, and depends on permanent vigilance.
Stronger action item: "Platform team will add an explicit environment confirmation to the deployment tool and integration-test it for production and staging by September 30. Owner: [role or name]. Tracking: [work item]."
Not every lesson deserves a large engineering project. Rank actions using the decision process your organization already trusts: impact, likelihood, cost, urgency, and interactions with other controls. Record when an action is deliberately not taken and why, so accepted risk does not disappear into silence.
Review action items after the meeting. An elegant document with permanently open tasks is not learning; it is an archive. If a date or owner changes, update the record and reassess the remaining risk.
Set expectations before the meeting: the purpose is to build an accurate shared model and choose improvements, not to decide who should feel worst. Share the document early enough for participants to correct facts without conducting the entire debate in comments.
Walk through the timeline and pause at decision points. Ask: "What information was available here? What assumptions were reasonable? Which signal was missing or misleading? What made recovery easier?" Invite the people closest to the work to add context without requiring them to defend their character.
Separate unresolved factual questions from improvement ideas. A meeting can end with an open technical question if someone owns the investigation. It should not manufacture certainty just to make the document feel finished.
If conflict appears, bring the group back to specific observations, consequences, and requests — the same foundation used for feedback without personal attacks. Serious conduct or policy concerns may need a separate, appropriate process; the postmortem should not be expected to resolve every personnel issue.
Your Incident Communication Checklist
During the incident: lead with impact, label the response state, separate facts from hypotheses, say what is being done, use the approved audience, and give the exact next update time. Keep the cadence even when there is no breakthrough.
After recovery: verify the resolution language, preserve the relevant timeline, identify contributing conditions, document what helped, and create owned, trackable actions. Explain decisions in the context in which they were made.
Before sending either kind of document, delete three things: unsupported certainty, personality judgments, and technical detail that the audience should not receive. Add three things if missing: user impact, uncertainty labels, and the next owner or update time.
Your next action: save the five-line Impact → Status → Evidence → Action → Next update template somewhere reachable during an incident. The best time to choose calm language is before the alert is firing.
Frequently Asked Questions
What should a software incident status update include?
Include the user or business impact, when it began if known, current response status, confirmed facts, mitigation in progress, any decision or action needed from the audience, and the time of the next update. Follow your organization's incident, security, legal, and external-communication procedures.
How often should you send incident updates?
Use a predictable cadence appropriate to the impact and your organization's response process. Fast-moving, high-impact incidents usually need more frequent updates than stable, limited-impact ones. State the next update time in every message and send an update then even if the message is 'no material change.'
What does blameless mean in a postmortem?
Blameless means the review seeks to understand decisions in context and improve the system rather than treating individual shame as the fix. It does not remove accountability. A useful review still names what happened, which decisions were made, what consequences followed, and who owns each improvement action.
What language should I avoid in an incident postmortem?
Avoid labels such as 'careless,' 'incompetent,' or 'human error' as the end of the analysis. Also avoid vague passive language that hides decisions. Replace judgment with observable facts, available context, missing safeguards, and contributing conditions: what the person saw, why the action seemed reasonable, and what will make the safer action easier next time.
Tough talks
Practice the conversation you’ve been putting off
Rehearse this situation with a realistic AI partner, then get specific feedback on what worked and what to try next.
Preview the practice scenario →Simon H.
Simon is the founder of Communication for Nerds. A lifelong nerd, he learned social skills the way he learns everything else: by breaking them into systems, practicing small reps, and keeping what works. Every guide here is what he wishes someone had told him earlier. Read his story →
