Crisis Communication

In an unprepared team, an outage starts a meeting before it starts a response. An incident — any event that affects the service — gets an engineer working on recovery within minutes, while telling anyone outside the company belongs to nobody in particular. Whether it can be disclosed, whose name it goes out under, and how much detail is allowed have never been settled, so the first half hour goes to settling them.

Picture document saving failing at two in the morning. Someone in the channel asks whether this needs an announcement. The marketing lead wakes up with no idea what happened. Somebody suggests legal should look at the wording first. Forty minutes pass without a single public line, and in that time users have posted about it themselves and confirmed to each other that it isn't just them. By the time the company says anything, the users' version of events is already the accepted one.

The damage comes less from the incident than from what silence lets people conclude. With nothing to go on, people assume the worst. Saving is briefly unavailable, and the story going around is that data was lost — and unwinding that story takes far longer than fixing the bug did. Crisis communication shortens that window by making the decisions ahead of time, so the moment of the incident is spent executing rather than deliberating.

The sequence starts with establishing facts and ends with an all-clear, with updates repeating at a promised interval in between.

1. Establish facts — narrow down what has been failing, since when, and who is affected. Whether it hits every user or one region, and whether data is gone or merely not displaying, changes every sentence that follows.
2. Assign a severity — the size of an incident's impact on the service is its severity, and it decides the level of response. A status page note, an email to every user, or full preparation for press questions all get chosen here. Getting this wrong in either direction is costly: a minor glitch mailed to everyone trains people to ignore the next mail, and a data issue left on a status page reads as concealment.
3. First notice — out within thirty to sixty minutes of detection. Four things go in it: what is happening, what is known and what is still unknown, what users should do right now, and when the next update will come.
4. Follow-ups — keep the time promised in the last notice, even with nothing new to report. "Still investigating, next update in an hour" beats silence. Miss that time once and nobody trusts the next one.
5. All-clear — confirm when service was restored and how far the impact reached. Any credit or refund terms belong here too, since customers who were affected will ask about them within the hour.
6. Aftermath — write the postmortem, the record of what caused the incident and what will change, and publish the part of it that can be shared when business customers are involved.

Four roles are needed, and each one enters at a different point.

• The source of facts — the on-call engineer, the person on duty to take outage pages. They join at detection and confirm what is affected and how far it reaches. The moment this person starts guessing, every sentence downstream becomes unreliable.
• The writer — the PR lead, in from the first draft. They translate the technical account into user language and hold the line between what is confirmed and what isn't.
• The external contact — one person takes every question from press and partners. Ideally it is whoever already handles media relations, the ongoing work of building ties with reporters. Two contacts means the company is on record saying two different things.
• The approver — the CEO or equivalent. A severe incident calls for apologizing in the company's name and committing to compensation, and nobody below that level can make the call.

Timing runs from detection as minute zero. All four are in one channel within fifteen minutes, the first notice goes out between thirty and sixty minutes, and the promised cadence holds from there. Incident response is the classic case of a war room, the temporary setup a team forms around an urgent problem. Assembling one after the fact burns half an hour just finding people.

"We don't need the cause to publish the first notice. Saying we don't know it yet is fine."

Don't hold the announcement waiting for a complete explanation.

"The status page covers this one. It isn't severe enough for a mail to everyone."

Match the channel to the size of the incident.

"Send every press question to me. Separate answers mean separate stories."

Keep the external contact down to one person.

Pagedeck once had document saving fail for twenty minutes. Theo caught it, a channel was open ten minutes later, and Ravi had the first notice out at the twenty-five minute mark. Nobody knew the cause yet, but two sentences went in: saving is failing, and anything you're writing is still in your browser, so don't close the tab.

Sofia sent the same message directly to the admins at paying accounts. A customer who reads a public notice and calls in has a different conversation than one the company reached first. Grace published the cause and the fix as an open post the following day.

The most common belief is that the accurate move is to wait until the cause is known and explain it all at once. The instinct behind it — don't publish anything unverified — is sound. But the purpose of a notice is not to explain the cause; it is to tell people what to do right now. Stay silent for the six hours a root cause takes and users spend those six hours inventing one, and the invented version travels faster than any correction. A precise explanation afterward costs far more effort than the early notice would have.

The other frequent belief is that apologizing admits liability, so the wording has to stay vague. Inside a company that reads as prudent risk management. But a line like "some users may have experienced inconvenience" denies nothing while spending trust. Readers take it as a sign something is being hidden, and reputational risk — the danger of losing trust badly enough to damage the business — grows more from sentences like that than from the outage itself. Stating confirmed facts plainly and labeling the unconfirmed as unconfirmed is the safer position legally as well.