Communication during response: IC, Ops and Comms roles and status updates Intermediate

This page answers: when several people respond together, who does what, and how to update stakeholders so nobody has to ask again.

Roles

The SRE Workbook defines three main roles: Incident Commander (IC), Communications Lead (CL) and Operations Lead (OL); CL and OL report to the IC. The SRE book adds a Planning role for long incidents.

Loading diagram…

Role	Does	Does not
Incident Commander	Holds the big picture, assigns work, decides on mitigation, maintains the incident doc	Debug hands-on (in a small incident one person may do both)
Operations Lead	The only group allowed to change the system during response	Change anything without telling the IC
Communications Lead	Sends periodic updates to the team, stakeholders and the status page	Promise a recovery time without evidence
Planning	Records how the system has drifted from normal (flags off, temporary config) so it can be reverted later	Skip “small” temporary changes

Practices to have

• A living incident doc. The SRE book treats this as the IC’s most important responsibility: a document recording what happens, possibly messy but usable. The postmortem timeline is built from it.
• Regular updates. The SRE Workbook only says “regular status updates” and does not prescribe a frequency. A common industry cadence is 15-30 minutes for severe incidents; what matters is always stating when the next update is.
• Clear handoff. The IC only leaves the role once the successor explicitly confirms (“You are IC from now on, ok?”), and the whole group is told.

Status update template

A good update has all five parts:

Part	Answers
Severity + time (UTC) + status	How serious, which stage are we at?
Impact	Who is affected, how, how many, since when? Any data loss?
Done	The latest action and its measured result
Next	The response team’s next step
Next update + IC	When will you hear more, who to ask?

[SEV2][14:35 UTC] Checkout slow — MITIGATING
Impact: ~30% of checkout requests > 2s since 14:05 UTC. No data loss.
Done: rolled back api v2.31 → v2.30 at 14:31, p99 is dropping.
Next: monitor for 15 minutes, confirm the cause.
Next update: 15:00 UTC. IC: @an

An update missing the impact and the next update time is a very common mistake — see the bad/good pair in Common mistakes.

Next: Blameless postmortem.