Why Your Status Page Is Not Your Monitoring (and What to Watch Instead)
September 1, 2026
The provider's status page answers a different question than the one you are asking. You want to know whether your service works right now; the page answers whether the provider has decided to announce something, after humans noticed, investigated, and wrote it down. Each step costs time, and the record of how much time is public. AWS's own post-incident report on the October 19, 2025 us-east-1 event shows impact beginning at 11:48 PM PDT and the first status update 23 minutes later. During the June 12, 2025 Google outage, the status page itself was down inside the failure for about an hour. If your monitoring feeds off the provider's feed, your monitoring inherits that lag and that failure mode.
What the status page is for
Statuspage, the Atlassian product behind a large share of the pages you check, describes its product as a communication tool in its own documentation: it does not ping your servers or your endpoints, and the company never recommends fully automating a status page. Green is the last thing a person typed. It stays green until someone changes it, and during the 2017 S3 outage AWS could not update its own health dashboard for about two hours because the dashboard's admin tooling depended on S3.
None of this makes status pages useless. They are the right source for scoped, human-confirmed statements during a long incident, and the right archive afterward. They are the wrong source for detection, because detection is a measurement and the page is a narrative.
What the SLA actually measures
The deeper mismatch is between what the page reports and what the SLA counts. Credits are computed from provider telemetry and your logs, never from the page.
| Provider | What the SLA measures | Where it comes from | Role of the status page |
|---|---|---|---|
| AWS | Error Rate per service per 5-minute interval: InternalError and ServiceUnavailable over your total requests (S3 example) | Provider billing and service telemetry, plus your request logs | None; claims list your logs, not page screenshots |
| Azure | Downtime minutes per service definition: minutes with no Virtual Machine Connectivity, for example | Provider telemetry, Service Health for your subscription | None; the public page explicitly excludes issues affecting only you |
| Minutes of Downtime per Downtime Period: loss of external connectivity or persistent disk access, full minutes only | Provider telemetry plus log files you submit | None; the page can be down inside the incident | |
| DigitalOcean | Monthly Uptime per resource: minutes of Unavailability over the month (Droplets) | Provider telemetry, account notices | Platform-level events only |
Read that table as a spec for your own monitoring, because it is one. The quantities that decide your money are error rates and connectivity minutes on the specific services and regions you use. A status page aggregates and lags; your probes measure.
The status page is a rumor with a timestamp. The SLA math runs on error rates and connectivity minutes, and every provider computes those from telemetry and logs, with no input from the page.
The monitoring stack that actually works
Four layers, in order of what they catch.
External synthetic probes. A probe on your critical endpoint, from a network the provider does not run, fails the moment your users do. This is the layer that caught the June 2025 Google outage in its first minutes for teams that had it, and it is the layer whose history doubles as claim evidence: probe logs with UTC timestamps show downtime periods directly.
Error-rate monitors. For API-dependent stacks, watch your own 5xx rate against the specific provider services you call. AWS's S3 SLA computes monthly uptime from your error rate in 5-minute intervals, so this is the number that maps one-to-one onto the claim math. Track it per region, because credits are per region.
Provider health feeds. Personal Health Dashboard events (AWS), Service Health (Azure), Cloud Service Health incident reports (Google), and account notices (DigitalOcean) tell you what the provider has confirmed and, eventually, what they will accept as an incident reference. Watch them; do not depend on them for detection.
The status page, archived. As supporting material in a claim, a status page capture is fine. As proof, it is worth nothing, and every provider's claim procedure asks for logs instead.
What to do this week
Pick the endpoint that costs you the most per minute of downtime, put an external probe on it from a different provider, and wire the alert to a channel a human reads. That single probe covers the detection gap the status page cannot close, and its log becomes the spine of the evidence file described in the evidence checklist. The measure-downtime-yourself method covers probe intervals, time sync, and monthly uptime math.
This layered picture is exactly how UptimeAudit watches the big four: service- and region-level monitoring of the providers' health feeds, independent of their status pages, with breach detection against the published SLA thresholds and a drafted claim when one crosses. The probe you set up this week does the same job for your own stack, for free.