Incident Status Updates — Language Exercises

1 / 5

An IC announces on the bridge: "We will send stakeholder updates every 15 minutes until we have a mitigation."
What is the purpose of defining a status update cadence?

Correct: B. Without a defined cadence, anxious stakeholders fill the silence by paging the IC, messaging the Ops Lead, or posting in the incident channel — all of which break the response team's focus at the worst possible time. A public commitment to "updates every 15 minutes" removes the need for stakeholders to ask, and makes the Comms Lead's job predictable and manageable.

With defined cadence	Without it
Stakeholders wait; response team stays focused	Stakeholders interrupt; IC loses focus on coordination

2 / 5

A status update reads: "We are actively investigating elevated error rates on the checkout service. More updates in 15 minutes."
When is "actively investigating" the appropriate phrase to use?

Correct: B. "Actively investigating" is the correct phrase when the team is working but doesn't yet have answers. It signals: (1) someone is responsible and engaged, (2) the problem is real and acknowledged, (3) more information will follow. Using it after a fix is deployed would be inaccurate; using it before any responder joins would be misleading. The phrase sets the right expectations for the current phase of response.

Incident phase	Correct language
Detecting / early diagnosis	"We are actively investigating"
Fix deployed, waiting for validation	"We have deployed a fix and are monitoring"
Fully resolved	"The incident is resolved"

3 / 5

An initial update says: "Customers may experience intermittent failures when completing checkout."
An experienced IC revises it to: "A subset of customers are unable to complete purchases."
Why does the wording matter?

Correct: B. "May experience" implies uncertainty and minimises the problem. When customers are actively failing to complete purchases, writing "may experience" is inaccurate and damages trust — customers know the situation is worse than the update suggests. Factual, specific impact language ("a subset of customers are unable to complete purchases") builds credibility and makes post-mortem SLA analysis straightforward.

Vague	Precise
"Customers may experience issues"	"A subset of customers cannot complete checkout"
"Some services are affected"	"The payments API is returning 503 errors for ~30% of requests"

4 / 5

The Scribe logs: "14:32 — IC declared SEV-1. 14:35 — Ops Lead identified connection pool exhaustion on replica-1."
Why is real-time incident timeline documentation important?

Correct: B. Without a real-time timeline, the post-mortem reconstructs events from memory and scattered Slack messages — an unreliable and time-consuming process. A live timeline also serves immediate operational needs: a responder joining mid-incident can read it to get current without interrupting the IC; the IC can scan it to avoid re-trying something that already failed. It is one of the Scribe's most valuable contributions.

Timeline use	Who benefits
Mid-incident: track what was tried	IC, Ops Lead, late-joining responders
Post-incident: base for post-mortem	Post-mortem facilitator, engineering leadership

5 / 5

A Comms Lead asks: "Should we update the public status page or just post in the internal Slack channel?"
What principle guides when to update a public status page?

Correct: B. Delaying a public status page update until after resolution is a common mistake. Customers see errors, contact support, and assume the company doesn't know about the problem. An early, honest update — even without root cause — acknowledges the issue and stops the flood of "is something broken?" support tickets. Transparency during an incident builds more long-term trust than a clean record that ignores visible problems.

Update timing	Customer experience
Early, before root cause	"Acknowledged — they know and are working on it"
Late, after resolution only	"They didn't know / didn't care — support tickets surge"