Writing Incident Communications

Option B is the standard incident executive summary format. In a live SEV-1, the VP needs to decide: does this require customer communication? Board notification? Do we need more resources? Every word of the summary should help answer those questions.

Five-part executive incident summary structure:

① Header with severity, component, scope, and elapsed time — "SEV-1 | Database outage | All paying customers | 12 min elapsed" — this can be read in 4 seconds and the reader knows the severity magnitude immediately.

② Current impact in business terms — "100% of paying customers, ~4,200 active sessions" — not just a technical metric. The VP uses this to decide if customer communications need to start now.

③ What you know / what you don't — "Replica is healthy. Failover has NOT triggered — investigating why." Two pieces of information: one reassuring (replica is fine), one concerning (why didn't auto-failover work?). Don't give only reassuring facts — the VP needs the full picture.

④ Current action with named owner — "On-call DBA is running diagnostics; manual failover decision pending in 5 min" — this shows the incident is managed, not chaotic. The 5-minute decision window is also critical: the VP knows there's a fork point coming.

⑤ Specific next update time — "14:55 UTC (in ~6 min)" — not "soon." The VP doesn't need to Slack you again, which keeps your incident channel clear of requests for updates.

Options C and D contain only sentiment ("working on it", "investigating") with no information useful for decision-making. "Sorry for the disruption" is appropriate in a customer email, not in an executive incident update.

Option B is the professional standard for customer-facing status page updates.

Status page update principles:

① Impact-first, non-technical — "Users may be unable to log in or access their data" — not "the RDS primary instance is not accepting connections." Customers' world is their workflow, not your infrastructure. Translate the impact into their language.

② Scope the impact clearly — "Core product features unavailable. Notification system and read-only features (exported reports) not affected." — this answers the question every partially-affected customer is asking: "is my thing broken?" Proactively telling customers what works preserves trust and reduces support ticket volume.

③ Don't share root cause until you're certain — "identified the affected component" — this is accurate and informative without over-committing. Saying "database issue" when you later discover it was a network partition causes a credibility problem. Share what you know; don't speculate on what you don't.

④ Commit to a specific next update time — "further update by 15:15 UTC" — this is the contractual element of incident communication. Every status update should either resolve the incident or commit to the next checkpoint. "We'll keep you posted" (Option C) is a contract breach — customers don't know how long to wait.

⑤ Apology at the end, not the beginning — lead with information, close with apology. This structure respects that the customer's primary need is to understand the situation, not to receive an emotional acknowledgement.

Option C over-discloses ("our database is down") and under-commits ("don't know when it will come back"). Option A is the classic boilerplate that says nothing specific and damages trust in status pages over time.

Option B is the model all-hands incident resolution notification.

The all-hands resolution message is different from both the live exec summary and the status page update. Its audience is your engineering team, and its purpose is threefold:
① Close the loop on an organisation-wide event
② Provide enough information that everyone understands what happened
③ Establish the post-mortem process clearly

Why each section matters:

Subject line format — [RESOLVED] + severity + component + timestamps — searchable in email, immediately communicates that the incident is over and provides the time window for anyone trying to correlate other events.

Root cause in the resolution message — "storage volume exhaustion + ENOSPC not included in healthcheck" — this is important: your engineering org deserves to understand what happened. Engineers who understand the failure are better positioned to spot similar risks in their own systems. Withholding the root cause until the post-mortem creates an information gap and reduces organisational learning.

"Auto-failover did not trigger because…" — naming the control failure is essential. The outage had two failures: the underlying storage exhaustion AND the monitoring/failover system failing to protect against it. Identifying both is honest engineering communication.

Immediate fix applied — this section proves that the incident resulted in a system change within the incident window, not just as a future action item. It's an organisational trust signal.

Post-mortem invitation — "all engineers involved in today's incident response" — this is a blameless culture signal. Incident participants are witnesses to complex system failure, not suspects to be held accountable in a post-mortem.