← All guides

The status page is green but the site is down — why that happens, and what to do

Updated 27 August 2026 · by Cassian Wei · 3 min read

Every large outage produces the same chorus: "the service is completely down but the status page says everything is operational." That's not (usually) a cover-up — it's how most status pages are built. This guide covers why official status pages lag reality, how to answer "is it them or me?" in under a minute, and how to stop depending on a vendor's self-reporting at all. (Disclosure: Watchpup, which publishes this guide, sells — well, gives away — independent monitoring. The first two sections are useful without it.)

Why the official status page is the last to know

  • A human has to declare the incident. On most platforms, the status page isn't wired to monitoring — it's a CMS. Something breaks, an engineer confirms it, someone decides it's incident-worthy, comms writes a careful sentence, someone with access posts it. Every step is reasonable; together they add up to the familiar 20–60 minutes of "operational" while your requests time out.
  • The wording is negotiated. Declared downtime can trigger SLA credits and contract clauses, so there's a standing incentive to say "degraded performance for some users" — and to say it late. Not fraud, just gravity.
  • Partial truths are true. "Some users in some regions" can be accurate at global scale while being a 100% outage for you. A status page aggregates; your traffic doesn't.
  • The status page shares the failure domain. If the page — or the monitoring that feeds it — runs on the infrastructure that just failed, it fails green. The best-run vendors host their status page with a different provider precisely because of this; not all do.

"Is it them or me?" — the 60-second triage

When a service you depend on stops responding, in order:

  1. Check from a network that isn't yours. A single independent HTTP check answers most cases instantly. Watchpup's instant check runs one from the network edge — no account, no JavaScript, and the result is a shareable link for the team chat: 
    curl "https://watchpup.watchpup.workers.dev/api/check?url=https://api.vendor.example/health"
  2. Phone off Wi-Fi. Crude, effective: if it loads on mobile data, the problem is between your network and them, not them.
  3. Crowd signal. Search the service's name on Bluesky or an outage aggregator. Fifty strangers posting "is X down?" in ten minutes is a better detector than most monitoring.
  4. The official status page — last. It's still worth reading (scope, ETA, workarounds) once an incident is declared. Just don't use it as the detector.

Monitor your dependencies like you monitor yourself

The durable fix: put your own checks on the third-party services your product depends on — the payment API, the auth provider, the email relay, that one webhook endpoint. When your app misbehaves, you'll know within a minute whether a dependency is the cause, from monitoring you control, with alerts in channels you watch.

curl -X POST https://watchpup.watchpup.workers.dev/api/monitors \
  -H 'authorization: Bearer wp_...' -H 'content-type: application/json' \
  -d '{"kind":"http","name":"Payments API","url":"https://api.vendor.example/health","interval":60}'

We eat this cooking: /s/mcp is a public Watchpup status page independently watching ten popular MCP servers we don't operate — real protocol handshakes every 5 minutes, uncoupled from any vendor's self-reporting.

If you run a status page: don't build the thing this guide warns about

  • Wire it to checks, not to a human. A Watchpup status page reflects live monitor state — when the check fails, the page shows it, no comms approval in the loop. You can still add human-written incident notes on top; the point is that the detector is automatic.
  • Host it outside your failure domain. If your product runs on provider A, your status page should not. (Ours runs on Watchpup's infrastructure, not yours — that's the whole point.)
  • Mind the alert-channel trap. If the thing that goes down is your email provider, email alerts die with it. Route alerts somewhere independent — Discord, Slack, a webhook, an address at a second provider. One alert channel that shares fate with the monitored thing is zero alert channels.

Honest limits

Independent monitoring has blind spots too. A single-vantage check can miss regional failures (green from our edge, down from yours) and can occasionally false-alarm on a network path issue. And the monitor itself can go down — the who-monitors-the-monitor problem never fully goes away; you can only move it onto infrastructure with a better track record than the thing being watched. The claim here is narrower than perfection: an automatic check from outside the vendor's walls will beat the vendor's own status page to the truth almost every time.

Watchpup is free uptime & cron monitoring — 1-minute checks, heartbeats, TLS/domain expiry, status pages, alerts everywhere. Sign up, try the live demo, or read more guides.