The status page nobody automated

When checkout breaks, every merchant on a platform writes to support inside the same ten minutes. Support then answers one sentence — “we know, we are on it” — several hundred times, while the people who could fix the thing are busy answering support. That volume is not a support-capacity problem. It is an information problem, and one public page fixes most of it.

We had nowhere to publish that sentence. Our health endpoints exist for the load balancer and answer a question — is this process up, can it reach the database — which is not the question a merchant is asking. The footer already said “Status”, pointing at nothing.

Nothing on it is automatic

No probes. No health checks feeding the page. No component that turns red or green on its own. A component is degraded when a member of staff has said so, and it recovers when a member of staff has verified it.

This is the decision most likely to look like laziness, so here is the argument. An automated status page is worse than none in exactly the case that matters. The check runs inside — or beside — the system that is failing, and the failure modes that generate three hundred support emails are precisely the ones a liveness probe reports as healthy: one payment provider timing out at authorisation, delivery emails queueing behind a stuck worker, one region slow.

A page that says “all systems operational” while merchants cannot check out does not merely fail to help. It tells every one of them the problem is theirs — and they write to support to say so.

Real automated status needs probes running outside the deployment, exercising real purchase flows, with enough hysteresis not to publish a red banner over one slow response. That is a service, not a feature. It can be added later underneath the same tables — an automated declaration would be a row written by a bot instead of by a person. Until then, the page says on itself how it is written.

The state moves only by posting an update

There is no route that edits an incident in place. Its status, its resolution time and its timeline all change in one transaction that also inserts the update explaining the change. The headline a merchant reads and the last message explaining it are written by the same statement, so they cannot drift — which is the failure mode of every status page that has ever said “resolved” above a timeline whose final entry is “investigating”.