Your status page should not share a host with the thing it reports on

There is a particular kind of bad morning where the incident is bounded, the fix is known, and the thing making it worse is that nobody can tell your customers what is happening.

Usually because the status page is behind the same load balancer, in the same datacentre, or on the same database as the system that just fell over.

The two failure modes

Shared fate. If your status page reads from the same database as your monitoring, a database problem is an outage and a communications blackout. You have lost the incident and the ability to talk about it in one move.

The thundering herd. A status page is idle for months and then, in the first ninety seconds of an incident, receives more traffic than the rest of the year combined. Everyone loads it at once, several times, and hits refresh. If it renders per request against a database, it becomes a second outage — one you caused by announcing the first.

What we do instead

Standby ships as two applications, and they are meant to be installed apart.

On-call holds incidents, escalation, schedules and silences. It is the system your engineers work in.

The status app runs on its own host with its own database. It does not read on-call’s data. It is told: on-call pushes HMAC-signed events — incident published, update posted, resolved, component status changed — and the status app applies them to its own store.

So the failure that takes on-call down does not reach the page, because there is no shared dependency to propagate through.

Serving a snapshot, not a render

The second problem needs a different answer. The public page is regenerated as a static snapshot rather than rendered per request.

An audience arriving all at once reads a file. That is the difference between a page that survives its busiest ninety seconds and one that does not.

There is also an RSS feed and a JSON summary endpoint, which matters more than it sounds: the people most anxious during an incident are often the ones who would rather subscribe than refresh.

The cost of doing it this way

It is a second deploy. A second host, a second database, a shared secret between them. That is real work and it is worth being honest about.

What you get for it is a page that is up when it matters, which is the only time anyone looks at it.

A test worth running

Stop your monitoring system — properly, not in a maintenance window — and load your status page.

If it still renders, the split is real. If it times out, you have a status page that works in exactly the conditions where nobody needs it.