Status Page

A status page is the public page on which a vendor reports its own availability: current state per component, open incidents, and a history of past ones. It is the first place anyone looks when a dependency seems to be misbehaving, and it is worth being precise about what it is — a self-reported, lagging instrument whose scope is defined by the party being measured. Each of those three properties has a consequence. Self-reported means the threshold for declaring an incident is a business decision as much as a technical one, and the page reflects what the vendor has decided is worth calling an outage. Lagging means the gap between the failure starting and the page turning yellow is the time it took a human to notice, confirm and write, which is why the page being green is not evidence that nothing is wrong. Scoped means the components listed are the vendor's own abstractions: a page can be entirely green while one region, one endpoint, one API version or one customer's account is failing, because none of those is a component on the board. None of that makes it useless. A status page is the fastest way to distinguish your problem from everyone's problem, which changes what you do next more than any other single fact during an incident. Subscribe to its feed, and read the post-incident write-ups when they appear, because they are frequently the only durable public record of what actually changed on the other side — and a vendor's willingness to publish detailed ones is a real signal during an evaluation. Just do not make it your detector. The thing that should tell you a dependency is failing is your own check against the endpoints you actually call, because it is the only instrument that measures your traffic rather than the vendor's aggregate. Record what you observed with timestamps while you observe it: service-level credits are claimed against evidence and are usually the customer's job to notice and request, not something a provider calculates on your behalf.