“Is [service] down?” How official status pages actually work

Something breaks, and the first move for most people is the same: search “is [service] down.” Not check the app again, not restart the router. Search it, because somewhere out there is a page that already knows the answer.

That page usually exists. Almost every major platform runs a status page now, a dashboard listing their systems and whatever’s currently wrong with them. But most people have never actually read one carefully, which means they miss both what these pages are good at and where they quietly fall short.

What a status page actually is

A status page is the company’s own admission, published by the company, about the health of its own systems. Slack has one, so does AWS, GitHub, Cloudflare, Google Cloud, Stripe, Discord, OpenAI, and pretty much every service with enough scale to need one. They typically live at a predictable address: status.company.com, or a standalone domain like companystatus.com.

Structurally they’re almost all the same, because most of them run on the same handful of status page platforms. You’ll usually find:

A component list, breaking the service into pieces. AWS doesn’t have one status, it has hundreds, one per region per service. Slack separates messaging, calls, notifications, and connected apps. This matters because a company can have a real, painful outage in one component while every other component reports green.

An incident feed, showing current and recent problems, each moving through a set of stages: Investigating (they know something’s wrong, they don’t yet know what), Identified (they’ve found the cause), Monitoring (a fix is deployed and they’re watching it hold), and Resolved. The gap between Investigating and Identified is usually the most informative part of an incident, because it tells you whether the fix is going to be fast or not.

A history log, letting you see incidents from the past days, weeks, or months. This is the part almost nobody scrolls to, and it’s often the most useful section on the page.

Why the history matters more than the current status

The live indicator only tells you about right now. The history tells you about the pattern, and the pattern is what actually predicts whether a service is a safe thing to depend on.

Cloudflare’s own status page logged thirteen separate incidents across eight days in August 2026, touching object storage, background workers, email security, and network performance across several regions. None of those thirteen alone was catastrophic. Together, in that window, they describe infrastructure under sustained strain in a way that a single “all systems operational” snapshot never would have shown you.

If you depend on a service for something that matters, read its history occasionally, not just its live status when something’s already broken. A service with a quiet history and an unusually long incident right now is a different situation than one that’s had a rough month.

The gap between something breaking and a status page saying so

Status pages are not automated. A human, or a team, decides when to open an incident, what to call it, and how severe to mark it. Every one of those decisions takes time, and every one of them can be wrong in either direction.

Independent outage trackers that monitor status pages alongside real user reports have documented this gap directly. One such tracker found that across a single month, it flagged dozens of real disruptions to a major provider’s services measurably earlier than the provider’s own status page acknowledged them, sometimes by more than two hours, and separately identified dozens more incidents that user reports clearly supported but that never received any official acknowledgment at all.

That second category is the one worth understanding. It’s not that companies are hiding outages. It’s that the bar for opening a public incident is usually “this affects enough customers, clearly enough, that it needs a public statement,” and a lot of real, frustrating problems sit just under that bar. Your specific account having trouble, a regional slowdown that hasn’t tripped their internal alerting yet, a partial degradation that only some customers notice. None of that guarantees a line on the status page, even though it’s completely real to the person experiencing it.

Reading between the severity labels

Most status pages use some version of three severity tiers, and knowing the difference saves you from either panicking or under-reacting.

Minor / degraded performance usually means something is slower or less reliable than normal, but mostly working. Worth checking again in a few minutes.

Partial outage / major usually means a specific feature or region is genuinely down for affected users, while the rest of the platform is fine.

Major outage / critical is the full, unambiguous “this is broken for everyone” tier, and it’s the rarest classification by design, because a company doesn’t want to trigger it lightly.

The February 2026 Cloudflare incident is a useful case study in how these play out in practice. A routing configuration change caused a subset of customers using Cloudflare’s bring-your-own-IP service to have their internet routes withdrawn entirely. Recovery took longer than a typical fix because reconnecting those customers required pushing a configuration update across Cloudflare’s entire global network rather than a single targeted patch. The incident stayed classified at a level reflecting a subset of customers throughout, even though for that subset it was total.

What to do when you can’t find a status page, or don’t trust it

Not every service publishes one. Smaller platforms, individual websites, and most businesses you’d actually be checking day to day have no public status page at all. And even where one exists, if you suspect the specific problem you’re facing isn’t severe enough to make it onto the page, you need another way to check.

This is where an independent check earns its place, because it isn’t waiting for anyone’s internal threshold to be crossed. Running the URL through CheckSiteStatus queries the site directly, from outside its own infrastructure, and reports exactly what came back rather than what a company decided was worth announcing. It won’t tell you what caused the problem the way an incident report eventually will, but it tells you the one thing a status page can’t promise instantly: whether the thing is actually reachable, right now, independent of anyone’s internal severity threshold.

The two approaches complement each other well. The status page tells you the official story once one exists. An external check tells you the ground truth immediately, which is often before the official story has been written.

If the specific question in front of you is a personal social or AI platform rather than infrastructure, we’ve covered the two most commonly searched cases directly: checking whether Instagram or WhatsApp is down and checking whether ChatGPT or OpenAI is having an outage, including where each platform actually publishes its status.

When the answer really is “just you”

A clean status page combined with a personal connection issue is the most common outcome of all this checking, and it’s worth remembering that before assuming the worst. If the official status is green and an independent down-checker also reports the site as reachable, the fault is almost certainly local: your network, your DNS, your browser, or something in between.

That’s a much smaller problem to solve than a genuine outage, and it’s usually fixed in under a minute.