"Everything should be back in thirty minutes." Four hours later the site is still down and leadership asks why we lied. Nobody lied on purpose: an engineer invented an ETA to calm support. In crisis, silence hurts; false certainty hurts more.
Communicating during an outage is not marketing. It is holding a shared truth thread between engineering, support, leadership, and customers — often while the host investigates on their side. Users evaluate not only downtime but whether you know what is happening and speak honestly.
Structure of an honest update
Each public or internal message should cover five elements in accessible language. First impact: who cannot do what — order, log in, receive email. Then scope: public site only or also back office, API, payment. Then status: investigating, identified, monitoring, or resolved. Next actions underway without excess jargon: "DNS failover in progress" works; "distributed cluster realignment" does not. Finally next checkpoint: fixed time for the next update, even if nothing new.
| Say | Avoid |
|---|---|
| "Payment unavailable since 14:03" | "Some slowness" |
| "Cause unconfirmed, host contacted" | "Bug at X" without proof |
| "Next update 15:00" | "Soon", "in a moment" |
| "Workaround: phone orders" | Invented ETA |
Coordinate host, status, and support
Three channels must stay aligned for the whole incident. On the host side, one ticket or escalation line: note incident ID and contact. Externally, the status page is source of truth; support always links there instead of improvising. Internally, macros aligned on the latest public status stop each agent telling a different story.
Leadership and legal should know revenue and data impact, not every technical guess. If the host communicates late, your duty remains to inform on your service down — without waiting for their press release.
Costly mistakes after the outage
Announcing resolved too early leaves CDN cache red while clients still see server errors. Premature blame on a module or vendor before analysis creates needless tension. Contradictory channels — reassuring social post, status still investigating — destroy credibility. Forgotten partners when an API is down leave B2B integrators without warning.
For upstream prep, cross-check your SLA and disaster recovery plan with message templates ready to fill in.
The peak: communication does not fix the outage
Host support may be excellent; if your customer line stays silent, it is your trust crisis — not theirs.
Decide and move forward without blind spots
Draft four message templates — from investigating to resolved — before the next outage, with fields to fill rather than invent under stress. Name a communicator separate from the engineer fighting the fire, if your organization allows. Link status page, support macros, and single social thread so one version circulates. Plan a post-mortem within five business days: causes, corrective actions, not a public blame hunt.
Frequently asked questions
What to say in the first incident message?
State user impact, scope, investigation underway, and a timestamped next update. Do not invent resolution time until engineering validates it.
Should I name the host publicly?
Yes internally and sometimes externally if infrastructure is likely at fault and B2B clients expect transparency. Avoid accusation without confirmation.
How to handle social media during outage?
One thread aligned with the status page and alert subscription link. Do not reply individually to every message if volume explodes.
When to announce "resolved"?
When business tests and metrics confirm normal service, after a monitoring phase — not when the host closes a ticket.
During an outage, the rule is simple: say what you know, say you do not know, say when you speak again. The rest is noise — or involuntary lie.