Your Provider's Status Page Is the Last Place You'll Learn You're Down

On June 12, 2025, Google Cloud went down. In the incident report that followed, Google explained why customers had to wait an hour to read about it:

The status page was late because the status page was inside the outage.

That single sentence is the clearest statement of a problem the entire industry works around and rarely says out loud. The page you check to find out whether a service is broken is built, hosted, and updated by the people whose service is broken. When the failure is big enough, it takes the announcement with it.

Google went further in the same report, and this part deserves to be read twice by anyone who runs monitoring inside the cloud they are monitoring:

This is not a one-off, and it is not unique to Google. AWS has documented the same shared-fate problem twice. After the November 2020 Kinesis event: "we were unable to update the Service Health Dashboard because the tool we use to post these updates itself uses Cognito, which was impacted by this event." In the same write-up, AWS notes the fallback was "a more manual and less familiar tool for our support operators."

Then again after the December 2021 us-east-1 outage: "the networking congestion impaired our Service Health Dashboard tooling from appropriately failing over to our standby region."

Meta hit it too, in its October 2021 global outage: "the total loss of DNS broke many of the internal tools we'd normally use to investigate and resolve outages like this." Not a status page failure exactly, but the same principle, one layer deeper. The tools you reach for during an outage are frequently downstream of the outage.

Even a status page built to survive can go dark

You might reasonably conclude the fix is to host your status page somewhere else. Cloudflare had already done exactly that. It did not save them.

At 11:20 UTC on November 18, 2025, Cloudflare's network began failing to deliver core traffic, in what the company called its worst outage since 2019. Their status page went down at the same time:

By their account it was a genuine coincidence. But the coincidence did real damage, because it misled the people best equipped to understand what was happening:

Cloudflare states plainly that they "initially wrongly suspected the symptoms we were seeing were caused by a hyper-scale DDoS attack." There was no attack. A database permissions change had caused an internal configuration file to double in size and exceed a hard-coded limit.

Sit with that for a second. For part of that incident, the best-informed people on earth about Cloudflare's network had the wrong model of what was wrong with Cloudflare's network. No status page could have told you the truth in that window, because the truth had not been established yet.

A status page reports diagnosis, not reality

This is the structural problem, and it has almost nothing to do with honesty. A status page is a communication tool. It publishes what a provider has concluded, after humans have noticed something, investigated it, agreed on its scope, and decided what to say. Every one of those steps costs time, and the first one is not free.

Your monitoring answers a dumber and far more useful question: is the thing working right now, from where my users are?

Different questions, different latencies. The gap between them is the window where your customers are already emailing you.

The company that makes status pages says this out loud

You do not have to take our word for any of it. Atlassian's Statuspage powers a large share of the status pages you check, and their own documentation is unambiguous about what the product is:

And on automation, their explicit recommendation runs the other way from what most people assume:

That is a defensible product position. Fully automated status pages really do flap and really do cry wolf, and a human in the loop produces better communication. But it has a consequence that should change how you read every green checkmark you have ever seen.

Green is not a measurement. It is the last thing a person typed. The component sits in its operational state until someone decides otherwise and changes it. Nothing is out there checking on your behalf, because, in the vendor's own words, that is not what the product does.

How long the gap actually is

Every figure below comes from the provider's own published incident report, or in the AWS case from an archived copy of AWS's own status feed. These companies deserve genuine credit: they publish detailed, unflattering, timestamped write-ups that let outsiders reconstruct what happened. Most companies publish nothing. The numbers are not an indictment of their engineering, they are evidence of how hard this is even for the best-resourced teams alive.

Azure: thirty minutes between knowing and saying

Microsoft's Post Incident Review for the October 29, 2025 Azure Front Door outage publishes its own minute-by-minute timeline, and it is unusually candid.

Customer impact began at 15:41 UTC. Monitoring alerts triggered an investigation at 15:48, seven minutes later. The first communication reached the public status page at 16:18.

Microsoft's internal detection was fast. The publishing was not. Thirty minutes passed between Azure knowing something was wrong and Azure saying so publicly, and Microsoft lists fixing exactly that as a completed repair item: "We have addressed delays in delivering alerts via Azure Service Health to impacted customers."

Worth noting for accuracy: Microsoft's preliminary review attributed the cause to an inadvertent tenant configuration change. The final review revised this to a sequence of customer configuration changes performed across two different control plane build versions, which produced incompatible metadata and exposed a latent data plane bug. The final version is the one to cite.

AWS: 23 minutes to a post that named nothing

AWS's post-event summary states that impact began at 11:48 PM PDT on October 19, when "all systems needing to connect to the DynamoDB service in the N. Virginia (us-east-1) Region via the public endpoint immediately began experiencing DNS failures."

An archived copy of AWS's own multi-service us-east-1 status feed shows the first public entry timestamped 12:11 AM PDT, twenty-three minutes later. In full, it read:

No service named. No cause. Not even confirmation that something was definitely wrong. That confirmation came at 12:51 AM, 63 minutes after impact, and still did not name DynamoDB or DNS.

None of this is unreasonable. You should not name a root cause before you have one, and AWS engineers did not identify DynamoDB's DNS state as the source until 12:38 AM. That is precisely the point: a responsible status page is necessarily slower than the outage it describes, because responsibility means waiting for certainty.

One more detail from that incident, for anyone whose escalation plan is "open a support case." AWS reported that a subsystem failure "resulted in the system unexpectedly blocking legitimate users from accessing support case functions." The outage took out the way you report the outage.

When the outage eats the way you'd announce it

The most vivid case belongs to Atlassian, and to their credit they documented it themselves in an unusually candid post-incident review.

In April 2022, a faulty script permanently deleted sites for a set of customers. The first support ticket arrived at 07:46 UTC on April 5. The first Statuspage update went up at 09:03 UTC, about an hour and a quarter later. Atlassian's first broad public acknowledgment, a tweet, came at 00:56 UTC on April 7: roughly 41 hours after that first ticket.

The reason is the part worth remembering, and it is not incompetence:

The outage destroyed the records needed to tell people about the outage. Affected customers also "could not reach our support team through the normal online contact form." Atlassian's own conclusion: "Rather than wait until we had a full picture, we should have been transparent about what we did know and what we didn't know."

Sometimes the acknowledgment never comes

On July 22, 2026, three days before this was published, Facebook, Instagram, WhatsApp and Messenger broke for users across Europe, the UK and the US. Reports started around 10:40 GMT and Downdetector peaked at roughly 6,000 for Instagram alone. It was Meta's second such disruption inside 72 hours.

Meta has published no root cause, no post-mortem, and no acknowledgment of any kind.

We verified that rather than assuming it, because absence of evidence is easy to get wrong. Meta's business status site exposes a machine-readable incident history. That history holds entries for July 6, 16, 19, 23 and 24, 2026. It holds nothing for July 22. The system was demonstrably working and logging incidents on both sides of the gap. Meta's engineering blog ran nothing incident-related all month. Meta's newsroom published on July 22 itself: a WhatsApp feature announcement.

A caution if you go looking for yourself. Several widely shared "Meta apologizes" quotes attached to this outage are misdated. The "technical issue caused people to have difficulty accessing our services" apology is from March 2024. The "we're 99% of the way there" post is from December 2024. The "we're coming back" statement belongs to a different and much larger Meta outage on June 12, 2026. The DNS explanation circulating in coverage is unattributed analyst speculation that Meta has never confirmed.

This is not only a provider problem

It would be convenient to conclude that the fault lies entirely with slow vendors. The survey data does not let you off that easily.

New Relic's 2025 Observability Forecast, fielded by Enterprise Technology Research across 1,700 IT practitioners and leaders, puts the median time to detect a high-business-impact outage at 35 minutes, falling to 28 minutes for teams with full-stack observability. In the 2024 edition, 29% of respondents put their detection time at an hour or more.

The same 2025 report found that 41% of the leaders surveyed still learn about service interruptions through customer complaints, incident tickets, or manual checks. That figure bundles those three routes together, so it is not a clean measure of "a customer told us first," but it is the closest published proxy that exists.

Put the two halves together and the picture is uncomfortable. Your provider may take half an hour to post. You may take half an hour to notice. Those clocks run at the same time, and your customers are inside both of them.

So what does tell you the truth?

One thing only: an independent observer, outside your infrastructure and outside your provider's, repeatedly asking whether the thing works.

That is not clever. It is just the only signal that does not wait on the failing party to understand its own failure first.

The honest case for status pages

We build status pages, so let us be straight about what they are for.

A status page is the right tool for telling users what you know and what you are doing about it: structured updates, component-level detail, a clean timeline, subscriber notifications. A company without one looks worse than a company with one, as Meta's July 22 silence demonstrates.

What a status page cannot be is your detection layer. And the fix is not complicated. A status page is only as fast as whatever feeds it. Fed by a human who must first notice, investigate and conclude, it will always lag the outage by exactly that long. Fed by monitors watching from outside, its components move when reality moves.

That is the difference between publishing your diagnosis and publishing your observations. Both belong on a status page. Only one of them can be fast.

Check something right now

If you landed here because something feels broken and the official page says everything is fine, these run independently of the providers they watch:

None of the incidents above were attacks. A race condition in DNS automation. A permissions change that doubled a file. Two build versions producing metadata that could not be read. In every documented case there was a window, from 23 minutes to over an hour, where the provider had not yet said anything, because it did not yet have anything reliable to say.

You cannot close that window. You can stop being on the wrong side of it.

One last thing worth saying plainly. Almost every source in this article is a company voluntarily publishing an unflattering account of its own failure: Google admitting its status page was inside the blast radius, AWS admitting its dashboard tooling depended on the service that broke, Cloudflare admitting its engineers chased a phantom attack, Atlassian admitting it went 41 hours without a broad public word. That transparency is what made this article possible, and it is the opposite of the behaviour being criticised. The problem here is structural, not moral. The companies that publish nothing are the ones you should worry about.

Site Qwality runs checks from multiple regions, asserts on page content rather than status codes alone, and routes alerts through channels that do not depend on the system being watched. If your provider's status page is the first thing you check during an incident, you are already behind.

Sources

• Atlassian: Know when to automate your status page (Statuspage documentation)
• Atlassian: Post-incident review of the April 2022 outage
• Google Cloud: Service Control incident report, June 12, 2025
• AWS: Summary of the Amazon Kinesis Event in Northern Virginia, November 25, 2020
• AWS: Summary of the AWS Service Event in Northern Virginia, December 7, 2021
• Meta Engineering: More details about the October 4, 2021 outage
• Cloudflare: outage on November 18, 2025
• Cloudflare: outage on February 20, 2026
• AWS: Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1)
• Microsoft Azure: Post Incident Review YKYN-BWZ, Azure Front Door, October 29, 2025
• New Relic: 2025 Observability Forecast (fielded by ETR, n=1,700)
• Meta Business status (incident history checked July 25, 2026)