Status pages should show the bad days
A wall of green squares is a marketing asset, not a status page. We rebuilt ours to make degradation visible.
Our status page was green for four months, including a Tuesday afternoon when a third of requests to two APIs returned errors for nineteen minutes. That is not a monitoring failure. It is a design failure, and it was ours.
How status pages lie
Most status pages have three states: operational, degraded, and down. A human sets them. Humans are reluctant to set anything other than operational, because doing so is an admission, and there is always an argument available that the incident was partial, or brief, or affected only some customers.
The nineteen-minute incident was all three of those things. It was also nineteen minutes during which our customers' code was failing, and the page told them the problem was on their end.
What we changed
The status page is now generated from the same measurements as the metrics, with no human in the loop for the automatic part. If the error rate for an API exceeds its threshold for more than sixty seconds, the page says so while it is happening, not after someone has decided how to characterise it.
We show ninety days of history per API as a bar per day, coloured by the worst sustained state that day rather than the average. Averaging is how a bad hour disappears into a good day.
Humans still write the incident notes, because a machine cannot tell you what happened or what changes as a result. But they cannot change the colour of the bar.
The uncomfortable part
Our page is no longer all green, and it never will be again. Two APIs have visible bad days in the last quarter. We have had exactly one prospect ask about them, and that conversation went better than any conversation we have had about a page full of green squares.
A status page that is always green tells a careful reader only that you are not measuring.