You noticed at 14:05. The status page updated at 14:40. That gap is not incompetence and it is not a conspiracy — it is the natural consequence of how status pages are produced. Understanding why makes them useful again, as one input rather than the answer.
Three structural reasons ¶
1. It is updated by a person, after confirmation
Almost no status page is driven directly by monitoring, and for a defensible reason: an automatically-published incident that turns out to be a monitoring fault is worse than a delayed one. So a human has to see the alert, confirm it is real, decide it is customer-affecting, and write something.
Every one of those steps is minutes, and the confirmation step is the slow one — because the first question an on-call engineer asks is exactly the question this site exists to answer: is it actually broken, or is it our monitoring?
2. Its components do not match your experience
A status page lists the components the vendor chose to name, usually along team boundaries. You experience the product. When "API" covers a dozen services and one is failing, the page shows green for eleven and the operator must decide whether one-twelfth of a component is worth a yellow badge.
Partial failures fit this model badly, which is why they are systematically under-reported. A service that is broken for 5% of users has no honest colour, and the internal argument about which one to use is itself a delay.
3. Publishing has a cost the vendor is aware of
Status pages feed uptime SLAs, procurement reviews and press coverage. That does not mean vendors lie — most do not — but it does mean the bar for "is this an incident" sits higher than the bar for "is a user annoyed". A brief degradation that recovers before anyone finishes writing about it often never appears at all.
What to read instead, and alongside ¶
- Your own measurement. A check you control answers immediately and describes exactly the endpoint you care about, which no vendor page does.
- Your error rates. The most reliable signal that a dependency is failing is your own application's logs. It leads the status page by the entire confirmation delay.
- Independent probes. Ours report what was measured, when, and by which method, so you can judge the evidence rather than accept a badge. The live outages page and per-service history are built for that.
- The vendor's engineering channels. Support accounts and community forums frequently acknowledge a problem well before the status page changes, because the bar for a reply is lower than the bar for a published incident.
Reading a status page well ¶
- Green means "not yet confirmed", not "fine". Absence of an incident is weak evidence.
- Check the timestamp, not just the colour. A page that has not been touched in six hours during a live problem is telling you about its own process.
- Read the component names literally. If your failure is in something not listed, no colour on that page will ever reflect it.
- Subscribe to updates rather than refreshing. The notification arrives when the page changes; watching it costs attention you need elsewhere.
If you run one ¶
Three things make a status page trusted rather than merely present:
- Publish partial degradation as itself. "Checkout is failing for approximately 5% of requests" is more useful than green, and more honest than red. Users forgive precision; they do not forgive being told nothing was wrong.
- Name components the way customers experience them. If nobody outside your org knows what the component is, it cannot tell them anything.
- Post the acknowledgement before the diagnosis. "We are investigating reports of failures in X" costs nothing, takes thirty seconds, and closes most of the gap this article is about. Waiting for a root cause is what produces the forty-minute silence.
The gap will never be zero, because confirmation is genuinely valuable and genuinely slow. But most of it is the acknowledgement, not the investigation.
The incentive nobody states out loud ¶
Published incidents feed SLA credits, procurement questionnaires and renewal conversations. That does not make vendors dishonest — most are scrupulous — but it does mean the bar for "this is an incident" is set by people who know what crossing it costs, and it sits higher than the bar for "a customer is having a bad time".
The practical consequence is predictable: brief degradations recover before anyone finishes drafting, partial failures get argued about, and the events most likely to be published are the ones too large to omit. If your experience keeps not appearing on status pages, that is the mechanism, and it means your own measurement is not optional.
Reading a post-incident report ¶
The write-up afterwards is usually more honest than the live page was, because the pressure has passed and the audience is technical. Three things worth extracting from one:
- Time to detection versus time to publication. If they detected at 14:05 and published at 14:40, that gap is your expected blindness next time. Plan for it rather than hoping it shrinks.
- Whether the trigger was monitoring or a customer report. "We were alerted by customer reports" is the single most useful sentence in any RCA, and it tells you their coverage has a hole your traffic sits in.
- What they changed about detection, not just about the cause. A fix that prevents this one failure is worth less than a change that shortens detection for the next unrelated one.
None of this requires cynicism. It requires treating the page as one input with a known latency, which is exactly what it is.