Your status page is an incident-communication tool, not a dashboard

A status page looks like a dashboard. Coloured squares, uptime percentages, a row of days going back three months. That resemblance is the trap. A dashboard exists so you can see the state of your system. A status page exists so someone who cannot see your system at all — a customer whose checkout is failing, a support agent taking the fourth ticket in ten minutes, an engineer at a company that integrated your API — can decide what to do next.

Those are different jobs, and only one of them is solved by a colour.

Red is a fact; an incident is a claim

Automatically flipping a component to red when a probe fails is the easy part, and it is roughly correct: the component genuinely isn't responding, and a visitor deserves to see that. In Tower, that state comes from the same evaluation the dashboard uses — a check that is down reads down on the page, a check under a maintenance window reads under maintenance rather than down, and a check that is up but failed earlier today reads degraded.

Publishing an incident is a different act. An incident says: we know, this is what it means for you, and here is what happens next. Automation knows none of that. It knows one component stopped answering. It doesn't know whether the blast radius is every customer or three in one region, whether writes are lost or merely delayed, or whether the fix is a restart or a restore.

So Tower splits the two. A failing component turns red on its own. An incident gets drafted — title, severity, affected components, and a first timeline entry already timestamped — and then it stops and waits for you. The draft is private. It sits on your dashboard marked to review, and nothing reaches your visitors until a human presses publish. Once you do publish, the automated follow-ups (it spread, it recovered, it's stable) post publicly too — that's what approving it means.

The reasoning is narrow: words written in your voice, on your page, under your logo, should be read by you first. The draft removes the blank page at 03:00, not the judgement.

A few consequences of that split worth knowing, because they're the ones people ask about:

• The title uses the component's public display name — "API", not prod-api-lb-healthz. A draft can't leak an internal hostname into copy you publish half-awake.
• Automation never grades an outage as minor. It only ever drafts on a component that is fully down, so it writes major, or critical when every component on a multi-component page is failing.
• If you already have a hand-written incident open on the component that just failed, you get no draft. You've already told them.
• Automation never touches an incident you wrote. Resolve or delete its draft while the check is still down and it stays quiet — it speaks again only if that component goes down again, afterwards.
• Visitors never see which incidents began as drafts. Whether a robot typed the first sentence is your business.

The first update, when you know nothing

The first update is the hardest one to write, because the honest content of it is "something is broken and we don't know what." People delay it waiting for a cause, and the delay is the mistake: the ten minutes you spend diagnosing before posting are the ten minutes your customers spend deciding whether the problem is you or them.

Write it without the cause. The draft Tower starts you with is deliberately flat:

Our monitoring stopped getting a response from API at 2026-09-21 03:12 UTC. We're investigating.

That's publishable as-is, and publishing it in ninety seconds beats a better sentence in twenty minutes. If you have another thirty seconds, add the two things automation can't know — who is affected and what to do meanwhile:

Our monitoring stopped getting a response from API at 03:12 UTC. API requests are failing for all customers; the dashboard and webhooks are unaffected. We don't know the cause yet. Next update by 03:45 or sooner if we learn something.

Three things that short paragraph does and "We are investigating an issue" does not: it bounds the damage, it tells someone whether to keep retrying, and it makes a promise with a clock on it. Never claim a cause you haven't confirmed — a retracted diagnosis costs more trust than an admitted unknown.

Cadence is the product

Here is the pattern that fails, which you have read a dozen times:

09:14  Investigating — we are investigating elevated error rates.
13:22  Resolved — the issue has been resolved.

Four hours of nothing. Technically accurate, completely useless. In that gap every reader concluded, in order: you didn't know, then that you'd forgotten, then that the page was abandoned. They went to Twitter, opened tickets, and told their own customers something worse than the truth because you gave them nothing better.

Nobody expects a fix in four hours. They expect to know you're still there. The rule that survives contact with a real outage: post on the interval you promised, even when there is nothing new. "Still working on it, no change since the last update, next one by 11:00" is a complete and useful update. A sensible default is every 30 minutes while a major incident is open, hourly once it is understood and the fix is grinding, and always a concrete time for the next one.

Use the status vocabulary as real beats rather than decoration — investigating (we don't know), identified (we know, we're fixing), monitoring (the fix is in, we're watching), resolved. Note that automation never writes identified: knowing what broke is a human claim, so that word is always yours. Moving to identified is the single most reassuring update you can post, because it converts "these people are lost" into "these people are working."

On the closing beats, Tower does help. When everything comes back up it posts a monitoring update rather than declaring victory, and only marks the incident resolved after 15 minutes of stability — measured from the last update on the timeline, so if you post "still watching this" during the window, the clock restarts rather than cutting you off. A check that drops, recovers and drops again inside that window stays one incident with an honest timeline instead of three mystery blips. It's the same instinct as pausing alerts without pausing the check: the measurement and the message are separate things, and conflating them makes both worse.

The test

After it's over, reread the timeline as someone who doesn't work for you. Can they tell what was broken, roughly how long, whether it touched them, and whether anyone was awake? If yes, the page did its job — regardless of how red the squares got.

The squares are the easy half. The writing is the product.

More on the monitoring underneath: multi-region confirmation before anything is called down, and what status pages include.