Why Uptime Bars Should Come From Checks, Not Incidents

Status pages mix two very different things: measured uptime data and human-written incident notes. When the uptime bar is built from incidents instead of raw checks, any outage that was never published, misconfigured, or added to the page after the fact can silently turn red days green.

A subtle bug makes this worse: many systems decide whether an incident is "public" once, at creation time, and never recheck that flag. Move a monitor onto a status page later, and its past outages stay hidden forever, even though the code looks like a live check.

The fix is to build the uptime bar directly from measured checks using a single confirmation rule, such as requiring multiple regions to fail across multiple consecutive checks before counting downtime. Critically, the same rule should drive both alerting and the public timeline, so on-call pages and the status page never disagree. Incidents and postmortems remain a separate, human-written layer for context, not for determining what counted as down.

Engineers can test any status page in minutes: add a monitor after an outage and see if history stays clean, unpublish a real incident and see if the bar turns green, or trigger a single-region blip and see if it overreacts. This distinction matters for anyone building monitoring infrastructure or evaluating vendor status pages for SLA trust.