The provider's status page still shows everything normal thirty minutes into an outage you can measure — why, and what do you use instead?

## What a status page actually is It is tempting to read a provider's status page as a monitoring dashboard published outwards — a live feed of the provider's own health checks. It is not. It is an **edited public statement** about a multi-tenant platform, written under the knowledge that it will be quoted in support tickets, in contract discussions and in the press. That framing explains almost everything about how it behaves, including the part that frustrates you most: it is optimised to be right rather than to be early. ## The steps before a post exists Between the moment your customers start failing and the moment anything appears publicly, several things have to happen in order. 1. **Detection.** The provider's own monitoring has to notice. If the incident involves shared services, the provider's monitoring may be partially impaired by the same event — the same blindness that is affecting you. 2. **Confirmation.** A single anomalous signal is not posted. Someone has to establish that the degradation is real and not an artefact of the monitoring. 3. **Scoping.** A public statement names which services and which regions are affected. Getting that wrong publicly is worse than being late, so scoping is done carefully rather than quickly. 4. **Approval.** The wording is reviewed before it goes up, because it is a statement the provider will be held to. None of those steps is negligence and none of them can be skipped. The lag is structural, and it is measured in the same units as your incident. ## Why it is also coarse Even once posted, the page is a blunt instrument. - It is published **per service and per region**, not per tenant, so an impairment affecting a subset of accounts may never show up at all. - Its severity vocabulary is small — normal, degraded, disrupted — and a partial degradation of one dependency can sit inside 'normal' for a long time. - It describes **the provider's services**, not your application, so it cannot tell you whether the thing your users are complaining about is affected. Combine those with the lag and you get the practical rule: **absence of a post is not evidence of health.** A green page is consistent with an enormous incident that has not been confirmed yet. ## What to use in the first thirty minutes Rank by independence from the failure, exactly as you would with any signal in this class. | Source | Available when | What it gives you | |---|---|---| | Customer reports and support volume | Immediately | Proof that impact is real, with no detail | | A probe outside the platform | Immediately | Whether your endpoint answers right now | | Your own error shapes at the edge | Immediately, if the edge still reports | Which dependency is failing, roughly | | Provider support channel | Minutes, if you have a path to one | Sometimes ahead of the public page | | Provider status page | Late | Scope, and the all-clear | The first two are the ones that decide whether you act. Waiting for the page before mitigating simply adds the provider's publishing cycle to your customer's outage. ## What the page is genuinely good for Once it exists it becomes useful in two specific ways, and it is worth being precise about them rather than dismissing it. First, **scope**: knowing which services and which regions the provider has named tells you whether the place you were about to move traffic to shares the affected blast radius, which is a question you cannot answer from inside. Second, **duration and the all-clear**: the eventual resolution note, and the incident summary that follows it, are the record of what happened and are worth reading afterwards. What the page cannot be is the trigger for your own response, or a substitute for your own timeline of what your users experienced — that is yours to keep, because the page records the provider's view of its own services and nothing about your application.