When the Status Page Goes Dark: Measure Downtime Yourself

August 4, 2026

Your provider's status page is the weakest evidence you can attach to an SLA credit claim, because it is usually the last thing to change. AWS's us-east-1 incident on June 13, 2023 began at 11:49 AM PDT and eventually degraded 104 services, but the Health Dashboard's first public update did not appear until 12:08 PM. Nineteen minutes of silent green. That gap is normal, not a bug: status pages are announcements written by humans, and they describe regions, not your account. If you want a number you can file a claim on, you need your own probes, your own timestamps, and your own monthly math. Here is the method, with the exact numbers to compare against.

Why the status page lags reality

The status page is an announcement, not a measurement. In a widely read Hacker News thread on AWS status reporting, a former AWS engineer said posting a non-green status was a manager decision, which means it is not real-time at all. Other practitioners report status updates landing 30 to 40 minutes after a problem starts. By the time the page turns yellow, your customers have been failing for half an hour.

Granularity makes it worse. Provider status pages mostly report at region level, so a service can be down for every customer in one availability zone while the region row stays green, because the aggregate looks fine. Your SLA is per service, per region, sometimes per zone. The page you are watching does not even use the same unit as the contract you are claiming under.

Coverage is the third gap. IncidentHub, which aggregates status pages, counted 38 AWS outages in 2025, the shortest around 14 minutes and the longest about 15 hours. Those are the incidents the provider eventually acknowledged. Every minute before the acknowledgement exists only in your own telemetry.

None of this is a conspiracy. It is the difference between a marketing surface and a measurement surface, and claims need the measurement.

The status page is an announcement, not a measurement. At a 99.99% commitment the whole monthly downtime budget is about 4.3 minutes, and the status page may never mention the outage that eats it. Your own probes, your own timestamps, and your own monthly math are the only evidence a claim has.

What to probe, and from where

Probe the thing you actually depend on. If your application calls S3, probe an S3 endpoint from a script. If you run EC2 instances, probe their endpoints. Probing the provider homepage tells you the homepage is up, which is not the question.

Run probes from outside the provider's network: an office machine, or a small VPS on another provider. A probe inside the same provider fails exactly when the provider fails, so it sees nothing. Two independent locations are the minimum, because one probe cannot tell you whether the outage is yours or your ISP's. When two locations agree, you have a defensible start time.

Intervals decide what you can detect

The check interval sets your detection floor. At 5-minute checks, a 3-minute outage can pass completely undetected, and your monthly report says 100% while users saw errors. That is not a rounding error. At a 99.99% commitment the whole monthly downtime budget is about 4.3 minutes, so one missed 3-minute outage is the difference between a breach and a clean month.

Use 60-second checks for services with 99.99% commitments, and 30 seconds if you want a cushion. Monitoring tools commonly offer 60-second intervals, and several go down to 30 seconds from a dozen or more locations. The cost is log volume; the benefit is that an incident is bounded by a couple of minutes of uncertainty instead of invisible.

Declare "down" only after confirmation. Three consecutive failures at 60-second intervals means down, and three consecutive successes means recovered. Record both the first failure and the confirmed-down timestamps. The first failure is the honest start of the incident; the confirmation is the conservative one, and you get to choose which one you argue with.

Sync the clock before you need the logs

Probe timestamps are only as good as the probe host's clock. Run NTP on the machine doing the checks and verify it with timedatectl or ntpq -p. A drift of a few minutes can push your outage window across a month boundary, or misalign it with the provider's incident record, and that discrepancy is exactly what gets a claim bounced.

Record everything in UTC, and convert to local time once, at the end, for the humans. Claim evidence should state one timezone, and UTC is the one nobody argues with.

The monthly math

Providers evaluate SLAs over the billing month, so measure over the same window:

Availability = (total minutes - downtime minutes) / total minutes

A 30-day month is 43,200 minutes. The allowed downtime per commitment level:

Worked example. Your RDS database runs multi-AZ, which commits to 99.95%. In a 31-day month (44,640 minutes), your probes record 25 minutes of downtime. (44,640 - 25) / 44,640 = 99.944%, which is below 99.95%. The SLA is breached, and under AWS's credit schedule you are owed 10% of that service's bill for the region. A 25-minute blip is a claim. That is how thin the margin is, and why your own measurement matters: the status page may never mention it.

Two caveats keep expectations honest. Providers compute availability from their own telemetry and their own definitions, so your number is evidence, not the final word. Credits also apply only to the affected service in the affected region, not your whole invoice. The deadlines are short: 60 days for AWS and Azure, 30 for GCP and DigitalOcean. Miss the window and the credit is gone for good.

Keep evidence like a claims adjuster

Save every probe result, not just the outages. The monthly math needs the whole month, and a support case wants request logs that document errors during the claimed window, which your probe log is. A useful line has four fields: ISO 8601 UTC timestamp, target, HTTP status or connection result, response time.

Archive the status page during the incident. A screenshot or a web.archive.org snapshot captures the provider's own incident ID and their acknowledgement times. On AWS, the Health API (aws health describe-events) and EventBridge rules on the aws.health source deliver account-scoped events as they happen, which beats refreshing a web page.

Keep everything for the claim window plus a month. Cloud credits are not cash and the payout lands on a future bill, but a claim with clean timestamps and a cited SLA clause is a claim that gets paid.

Set up the probe today

Do it now, before the next outage, not during it. Self-host Uptime Kuma, or write a cron job that curls your endpoints and appends timestamped lines to a log, on an NTP-synced host outside the provider. Two locations, 60-second intervals, three-failure confirmation, UTC everywhere, and the rule written down. When the status page goes dark and the pager goes off, you will already have the evidence, and the credit claim becomes an hour of paperwork instead of a scavenger hunt. If you would rather not build the rig yourself, uptimeaudit.io watches provider status pages and health endpoints and turns observed downtime into claim-ready records; the method above works fine on a $5 VPS either way.