You are handling communications for an ongoing SEV1 outage where customer logins are failing. What goes into each stakeholder update, how often do you send one, and what should you never promise in it?

## What an incident update is actually for A stakeholder update is not a debugging log and not a status summary for your own team. It exists so that three groups can make decisions without interrupting the responders: support and account teams who are answering customers right now, leadership who may need to make a business call, and other engineering teams deciding whether to hold their own releases. Everything in the update should serve one of those decisions. Anything that serves none of them — stack traces, service names nobody outside the team knows, running commentary on a hypothesis — belongs in the responders' working channel. ## The three fields every update carries **Impact, in user terms, with a start time.** Not "the auth service is degraded" but "users cannot sign in; roughly 30% of login attempts have failed since 14:02 UTC; already-signed-in sessions are unaffected". Scope and magnitude matter as much as the symptom, because support answers different questions for "all customers" than for "customers in one region". If you have a workaround, it goes here — it is the single most valuable line in the update for anyone on a phone with a customer. **State of the response.** What is confirmed, what has been ruled out, what is being attempted right now. Label hypotheses explicitly as hypotheses. If a mitigation is in flight, say so and say what you will look at to know whether it worked. This is where a candidate reveals whether they understand the difference between reporting facts and leaking speculation: "we suspect a bad deploy" travels outward, gets repeated as fact, and has to be publicly retracted when it turns out to be a dependency. **The next update time.** This is the field people skip and the one that does the most work. "Next update at 15:00 UTC" converts an anxious audience into a patient one and stops the stream of individual "any news?" messages aimed at the people trying to fix things. Missing a time you committed to is worse than committing to a wider interval, so pick a cadence you can actually sustain. ``` SEV1 — Login failures Impact: ~30% of sign-in attempts failing since 14:02 UTC. Existing sessions unaffected. All regions. Status: Bad configuration rolled out at 13:58 identified as the likely cause (unconfirmed). Rollback started at 14:31. Next update: 15:00 UTC, or sooner if impact changes. ``` ## Cadence Tie the interval to severity and agree it in advance so nobody is negotiating it mid-incident: something like 30 minutes at the top severity, hourly a tier down, and always an immediate update on a material change — severity upgraded or downgraded, mitigation applied, impact ended. The heartbeat rule matters: send the update on schedule even when there is nothing new. "Still investigating, impact unchanged, next update 15:30 UTC" is genuine information. It says the response is alive and staffed. A gap says the opposite, and people fill silence with their own worst guess. ## What you never promise A restoration ETA. During an incident you rarely know the cause, so you cannot know the fix time; an ETA is a guess wearing the costume of a commitment. It propagates fast — support tells customers, customers tell their own users, someone builds a plan around it — and when it slips you now have two problems. The professional substitute is a next-update time plus, if you genuinely have one, a bounded statement about a specific action: "the rollback completes in about ten minutes; we will confirm recovery in the 15:00 update." Similarly, do not name a cause you have not confirmed, and never name a person or a vendor as the reason. ## Closing the incident out The final update must separate two things that stakeholders routinely conflate: **impact has ended** and **we understand why it happened**. Declaring recovery is a statement about the SLIs you are watching now; the explanation comes later. Say plainly that a postmortem will follow, and do not improvise a prevention plan in the resolution message. ## The cost side Updates are not free. Each one consumes a responder's attention at exactly the moment attention is scarcest, which is precisely why the cadence, the audiences and the template are settled before the incident rather than during it, and why the person writing them should not be the person deep in the debugger. That trade — a fixed, slightly generous cadence written by someone not on the keyboard, versus ad-hoc updates from whoever is closest to the problem — is the real decision behind the question.