Every company has a crisis communications plan for the big disaster - the breach, the recall, the founder scandal. Almost none have thought about the small, recurring one: the afternoon the product goes down for forty minutes and a few thousand people open a browser tab to find out why.
That tab is usually the status page. It is also, for most companies, the least designed piece of the entire customer experience.
The apology tweet is theater. The status page is the record.
A tweet says “we’re aware of the issue and looking into it.” It is written for people who are not affected, to signal that the company is paying attention. The status page is read by people who are affected, refreshing every ninety seconds, trying to decide whether to keep waiting or escalate to a support ticket. Those are different audiences with different needs, and most companies write for the first one and forget the second exists.
The person on the status page does not want reassurance. They want three things, in order: is this a known issue, what is actually broken, and when will it be fixed. A generic “we are investigating” answers none of them and reads as exactly what it is - a placeholder nobody has bothered to update.
Specificity is the whole product here
The best incident updates name the actual failure mode in plain language: “the payments queue is backed up, new charges are delayed but not failing” tells a customer something they can act on. “We are experiencing some disruption to service” tells them nothing, and it reads as evasive precisely because it is vague where it could easily be specific.
The timestamp cadence matters as much as the words. An update every fifteen minutes, even a one-line “still working on it, next update at 3:45,” builds more trust than a detailed post-mortem that shows up once, three hours late. Predictability during a wait is its own form of reassurance.
The post-mortem is the actual brand asset
The best thing to come out of an outage is the follow-up writeup: what broke, why, what changes as a result. Companies that publish these treat an outage as a demonstration of competence under pressure instead of only a lapse in it. Companies that skip it leave the story to be told by whoever was angriest in the support queue, which is rarely the most accurate version of events.
None of this requires a dedicated status-page vendor or a communications team. It requires deciding, before the next outage happens, who owns the page, what tone it is written in, and how often it gets updated while things are still broken. That decision made in advance is the difference between a status page that reads like triage and one that reads like a company that had already thought about this moment before it arrived.