What Cloud Status Pages Actually Cover, and What They Hide

August 7, 2026

Your provider's status page is a communication tool with a latency problem, not a monitoring tool and not a record of what happened. On October 19, 2025, AWS's us-east-1 region started failing at 11:48 PM PDT. The first entry on AWS's own status feed appeared 23 minutes later and named no service. Confirmation that anything was actually wrong took 63 minutes. On June 12, 2025, Google posted its first incident report about an hour after the outage began, because the status page's own infrastructure was inside the outage. None of that would matter much if the status page decided your SLA credits. It doesn't. Providers compute those from their own telemetry and your logs, with no input from the page at all. If you wait for a status page to prove an outage happened, you are wasting the claim window and skipping the evidence.

The page reports diagnosis, not reality

Atlassian's Statuspage product hosts a large share of the status pages you check. Its own docs say Statuspage is a communication tool, that it does not ping your servers or endpoints, and that the company never recommends fully automating a status page. Green is not a measurement. Green is the last thing a person typed, and it stays green until someone decides to change it.

A status page publishes what a provider concluded after humans noticed something, investigated it, and decided what to say. Every step costs time. Your monitoring answers a different question: is the thing working, from where your users sit? The gap between the two is the window where your customers are already emailing you.

How long the gap actually is

The numbers below come from the providers' own post-incident reports.

AWS's writeup says systems connecting to DynamoDB in N. Virginia "immediately began experiencing DNS failures"; 141 services were affected. Azure's review of the Front Door outage shows internal alerts fired at 15:48, seven minutes after impact, yet the public page got nothing until 16:18. Microsoft listed delays in alerting via Azure Service Health as a completed repair item. Cloudflare's post-mortem says its status page, hosted entirely off its own network, went down at the same time as the outage, and its engineers initially suspected a DDoS attack. The actual cause was a configuration file that doubled in size.

What the pages actually cover

Azure is the most explicit about coverage limits. Its docs say the public status page is used only for three scenarios: impact broad enough to hit a full region or multiple regions, an issue that stops you reaching the portal or Service Health, and broad impact where Microsoft cannot yet confirm who is affected. Everything else goes out as targeted notifications to affected subscriptions. The same doc notes the public page does not know which subscriptions and tenants you manage, so it cannot show smaller issues that affect only you. Your most important workload can be down for an hour while the public page stays green and Microsoft emails the tenants who are actually hit.

AWS's dashboard is per-service and per-region, updated by humans, and its writeups admit the update tooling depends on AWS services. In 2017, S3 went down and AWS could not update the Service Health Dashboard for about two hours because the admin console depended on S3. The 2020 Kinesis event took out Cognito, which the posting tool used. In December 2021, congestion impaired the dashboard's failover. Google admitted its first report on June 12, 2025 came about an hour after the start, because the Cloud Service Health infrastructure was itself down due to the outage. DigitalOcean's page at status.digitalocean.com follows the same model: platform-level events, human updates, separate from the per-Droplet math in its SLA documents.

The status page is not the SLA clock

This is the part that costs people money. None of the big four computes SLA compliance from the status page.

AWS's S3 SLA defines Monthly Uptime Percentage from the Error Rate per account, per 5-minute interval: internal errors and ServiceUnavailable responses as a share of your requests. AWS calculates it. To claim a credit you open a support case with "SLA Credit Request" in the subject, the billing cycle, the region, the dates and times of each incident of non-zero error rates, and your request logs. A status page screenshot appears nowhere on that list.

Google's Compute Engine SLA defines downtime as loss of external connectivity or persistent disk access for your instances, counts only full minutes, and requires you to submit log files showing the downtime periods. Azure's credit path runs through a Refund Request support ticket with the incident tracking ID from Service Health, and its docs tell you to watch Service Health, not the public page, to see what affects your tenant.

The status page is a rumor with a timestamp, not a record. SLA math runs on provider telemetry and your logs, and the page can lag by an hour or go dark entirely. A claim whose evidence starts and ends with a status page screenshot is a claim with no evidence.

So the page can be green while you are owed money, and red for an outage that never touched your account. Basing your incident response on it either way is a mistake.

What a hidden outage costs you

Silent outages are the norm. StatusGator's review of 2025 calls it the year of the global cloud outage, noting that many incidents never get published at all. IncidentHub tracked more than 48,000 outages across hundreds of services in 2025, and most never reached a public page, which means most never triggered a claim.

The deadline math makes this worse. AWS wants credit requests by the end of the second billing cycle after the incident, about 60 days, and the SLA stops applying after that with no appeal. The other three run their own windows, all under a quarter. If your first clue is a customer email and the page says "operational" for another hour, you are losing a window you did not know you were in. The credit is a percentage of what you paid for the affected service in the affected region, not your whole bill, and the claim is roughly an hour of work. The full thresholds and deadlines are in the claim guide.

Where the real signal lives

What to do instead

Run synthetic checks on your most critical endpoints from outside the provider, so a probe fails while the page still says operational; here is the method for measuring downtime yourself. Capture evidence at incident time, not after confirmation: UTC timestamps, error logs, failed request counts, and the incident ID from Service Health or the Personal Health Dashboard, per the evidence checklist. Keep status page archives as supporting material only, never as the proof.

The one action that matters most: before the next incident, pick the endpoint that costs you the most when it dies, put a synthetic check on it from a provider you do not depend on, and make sure the alert lands somewhere not hosted on that provider. That single check is the difference between knowing about an outage in the first minute and reading about it on a status page an hour later, after your customers have already told you.

That gap is what we built UptimeAudit to close: we watch the big four's pages and health feeds down to service and region, and when observed downtime crosses an SLA threshold we draft the claim before the window closes. The monitoring part, at minimum, you should have today.