When Your Status Page Says More Than Your Incident Plan

Most companies with a public status page bought it as tooling. Few treated it as a commitment. The moment the page exists, it makes three promises on your behalf: you will know when something breaks, you will say so promptly, and what you say will be true.

During an incident, customers do not read your incident response plan. They read the status page, or they read its silence. A page that says nothing for six hours says something. A page that says "investigating" for two days says something worse.

The fix is not better copywriting during a crisis. It is deciding, in advance and in writing, who speaks, what they may say at each stage, and how fast the page must move. That decision set belongs in the incident plan, rehearsed like any other part of it.

TLDR

• A public status page is a standing promise of detection, cadence and honesty.

• Silence and stale "investigating" notices are communication failures, not neutral states.

• Decide the approval chain and the first message for each incident stage before the incident.

• Align the page with legal and customer commitments so speed never outruns accuracy.

• Rehearse posting to the page the same way you rehearse the technical response.

The status page is a commitment, not a tool

Customers calibrate their trust on two signals: how fast the page moves and whether its language matches what they are experiencing. If their dashboards fail while your page shows all green, the page is not neutral. It is contradicting them, and they will remember the contradiction longer than the outage.

NIST's incident response guidance treats external communication as a core response function, with defined handlers and prepared interactions for outside parties. The status page is where that function becomes public. It deserves the same deliberate design as the technical response it reports on.

Where status pages and plans usually disagree

Four gaps show up repeatedly:

• No named owner. Engineering assumes communications owns the page. Communications does not know it exists. Nobody posts.
• No approval chain. The one person allowed to post is asleep, or the approval path runs through someone in the war room who has no time.
• No pre-agreed wording. Every sentence is drafted under pressure, so the safest sentence ("we are investigating") wins by default and stays up too long.
• No alignment with obligations. Customer contracts, regulators or disclosure rules require notice on a clock the status page does not know about.

Build the communication decision matrix

One page that answers, for each stage of an incident: what do we say, who approves it, and when do customers hear it first. The example below is fictional and illustrative; build yours around your real contracts and obligations.

Stage	What the page says	Approver	Customers told first?	Update cadence
Suspected issue	"Investigating reports of..." plus scope	On-call incident lead	No	Every 60 minutes
Confirmed impact	What is affected, what works, workaround	Incident lead plus comms	Yes, if service-impacting	Every 30-60 minutes
Mitigation underway	Cause category, next update time	Incident lead	Yes	Hourly or at stated time
Resolved	What happened, duration, follow-up date	Executive owner	Yes	Once, then post-incident note
Post-incident	Summary, cause, prevention steps	Executive owner plus counsel	Yes	Within agreed window

Two design rules matter more than any row. First, every stage names the next update time, so silence is always a choice, never an accident. Second, the approver column never contains a person who is also running the technical response.

Rehearse the page, not just the plan

If your next tabletop exercise does not end with someone actually drafting the status updates, it tested the technical plan only. Add a communications inject: thirty minutes in, the facilitator asks for the exact words that go on the page, the name of the approver and the time of the next update.

Teams that do this find their gaps in an afternoon. Teams that do not find them at 3 a.m. with customers watching. A broader look at building a resilient incident response program puts this in context.

Frequently asked questions

Who should approve status page updates during an incident?

A named communications approver who is not running the technical response, with a named fallback. The incident lead supplies facts; the approver owns the words and the timing.

How fast should a status page be updated during an outage?

Fast enough that the page never goes stale: commit to a cadence per stage (often 30 to 60 minutes during active impact) and always name the time of the next update. A promised update time kept beats a fast post followed by silence.

Should legal review status page wording before it posts?

Legal should pre-approve the framework and holding language in advance, not each post during the incident. Pre-agreed wording is what makes speed and accuracy compatible.

What if the status page is wrong about scope?

Correct it visibly and quickly, with the correction time-stamped. Customers forgive a corrected error far more readily than a page that drifts quietly from their lived experience.

A Defensible Next Step

Open your status page and your incident plan side by side. If the page promises a cadence the plan cannot staff, fix the plan or change the page before a customer finds the mismatch for you. Book a Decision-Clarity Call to build the decision matrix and run the first communications inject.