Incident Communications

Status page discipline, the 15-minute update cadence, and the structure of executive briefs.

Overview

High-leverage and underinvested

Customers, executives and internal teams all need updates during an incident, and doing it badly costs reputation. The good news: it's a learnable skill with clear patterns.

The audiences

Customers — Are you aware? What's the impact? When will it be fixed? — Status page within 5-10 minutes of detection, then every 15-30 minutes
Executives — How bad is it? Financial, customer and brand impact? What's being done? When will it be over? — Tight, factual 5-10 lines, every 15-30 minutes during a SEV-1
Internal teams — Should I drop what I'm doing? Can I help? What's the latest? — Incident Slack channel: pinned status at the top updated every 15 minutes; free-form discussion in threads

Technical jargon ("the etcd cluster is partitioned")
Speculative root cause ("we believe a deploy may have...")
"Investigating" for 2 hours with nothing new

Status page lifecycle

Identifier — "We are investigating reports of degraded checkout performance."
Impact — "Some customers may experience slow checkouts."
Mitigation — "We have identified the cause and are deploying a fix. ETA: 30 minutes."
Resolution — "Resolved at 14:23 UTC. No data was lost. Postmortem will be published within 5 business days."

An executive update

> Update 14:30 UTC: Checkout outage now at 23 min. Estimated 15K affected users. Mitigation in progress (rollback v3.2.1). ETA resolution: 14:45. No known customer-data impact. IC: Alice. Comms: Bob.

Status page best practices

Prefer "investigating" to silence — Customers panic at silence; "investigating" buys time
Don't speculate — "We believe X" can be wrong; "we are investigating Y" can't. Label any hypothesis: "Initial hypothesis: ..."
Fixed cadence — Even "no new information" is information
Detailed final update — Customers want to know what happened, not just "resolved"
Postmortem within 5 business days for major incidents — The public version is often shorter than the internal one

> [!WARNING] Host the status page independently of the systems it reports on. A self-hosted page in your prod region goes down with prod. Providers: Statuspage (Atlassian), Statusgator, Instatus, BetterStack, most with email, SMS, RSS and webhook notifications.

> [!TIP] The 15-minute rule: during a SEV-1, post every 15 minutes even without progress. "No new information; investigation continues; next update at HH:MM." Silence breeds anxiety; updates de-escalate.

> [!IMPORTANT] The Comms Lead is full-time and doesn't debug. Engineers asking the IC "what should I tell the customer?" is a smell; that's the Comms Lead's job.

Key concepts

Comms Lead: Dedicated role during a SEV-1. Owns customer + executive + internal communications. Full-time during the incident.
Status page: Customer-facing single source of truth during an incident. Independently hosted from production.
15-minute update cadence: Even with no new information, update every 15 minutes during a SEV-1. Silence breeds anxiety.
Identifier / Impact / Mitigation / Resolution: Standard structure for status page updates. Predictable for customers.
Don't speculate: Public statements should be facts ("we are investigating") not hypotheses ("we believe X caused..."). Hypotheses can be wrong.
Independent hosting: Status page MUST NOT depend on the production it's reporting. Statuspage / Instatus / similar third-party.

When to use it

Active SEV-1 / SEV-2 — Comms Lead is named and has a runbook
Onboarding the Comms Lead role — there's a real skill ladder here
Designing the status page — independent hosting, structured updates, customer-friendly language
Postmortem — comms is part of the timeline; what could be improved

Interview questions

What goes on a status page during an incident?
How do you write an executive update during a SEV-1?
Why is independent hosting of the status page non-negotiable?