Monitoring i status

Almost every status page you land on shows beautiful numbers. 100 percent uptime, all green, not a scratch. The trouble is that those numbers usually do not mean "everything worked", they mean "nobody was looking". Missing data gets counted as success, and the client gets a pretty picture with no backing in reality.

We built monitoring that does something harder than a pretty chart: it tells the truth, even when the truth is inconvenient. When we do not know how a service behaved, the result should read "I don't know", not "all is well". On top of that comes a public status page with an honest history and incident handling run where the team already sits. This case study is about counting availability without fooling yourself.

The mechanism of a typical status-page lie is trivial. If in a given period the probe collected no samples, and yet you count that period as healthy, your uptime will always look great. The less often you look, the better you come out, which is absurd: a tool for watching availability rewards you for not watching.

The effect is convenient and untrue. A green chart reassures the team and the client, even though underneath there could have been an hour nobody knows anything about. We wanted exactly the opposite stance: "I don't know" should mean "I don't know", not be quietly rounded up to "everything works".

The whole honesty of this monitoring comes from one decision: a sample has three possible states, not two. Not just "up" and "down", but also "unknown" for the time when there simply was no observation. That distinction is the heart of everything else.

Only samples actually collected go into availability, that is the "up" and "down" ones. The "unknown" states are set aside, because you must not fake them in either direction. If there was no observation in a period, the result is not 100 percent and it is not zero. The result is empty, and that is exactly how the status page shows it.

A separate trap is scheduled downtime. It is tempting to count a maintenance window as healthy time, because "it was a planned break, not an outage". Except then the chart lies again, just more subtly: it pretends the service was running when it was deliberately gone.

We went with a middle that is honest in both directions. Maintenance windows are marked separately and do not count as downtime, because they are not an outage. But they also do not pretend everything was running then. The chart shows a gap marked as maintenance, not a fake green background. It is the same principle that governs the whole project: we do not round in our own direction.

Monitoring that only counts is half the job. The other half starts the moment something actually breaks. Here the classic mistake is committed: incident handling is pushed into a separate tool nobody wants to log into in the middle of a fire. We went where the team already is, that is Discord.

The flow is short and needs no context switch. A service state change fires a notification. An incident is opened and updated straight from the channel, without logging into another panel. The public status page shows clients the timeline and the close, clearly and without dressing it up, as honestly as the uptime numbers.

The number on the page means exactly what it says. When it reads 99.5 percent, that is 99.5 percent of actual observations, not an artifact of the probe sleeping for half a day. The client looks at the status page and sees an honest history: availability, downtime and maintenance windows kept apart, not eternal green that means nothing.

When something breaks, the team runs the incident from the place it already is, without logging into another tool at the worst possible moment. The whole thing holds to one principle that looks modest and is rare: monitoring you can trust, because it admits what it does not know instead of painting the gaps green.