When Cloudflare Goes Down: A Survival Guide for Your Team
Users start reporting your site is down. You SSH into your server — it's fine. Nginx is running. The app responds to curl. Everything is healthy... on the origin. But Cloudflare's edge is returning 522 errors to your users. Your server is up. Your site is down. And you're debugging the wrong thing.
What Happens on Your Team
The DevOps / SRE Engineer
Checks the origin server — all green. Checks Cloudflare's dashboard — it's loading slowly. Sees 522 errors in the analytics. Tries to purge the cache — the purge API is also slow. Realizes the issue is between Cloudflare's edge and the origin, and there's nothing they can do except wait.
The real cost: Cloudflare issues are uniquely frustrating because your origin is healthy. You can't fix the problem by restarting services, rolling back code, or scaling servers. You're dependent on Cloudflare resolving their edge network issue. The only thing you control is communication.
What they should have had: Two monitors: one for the public domain (through Cloudflare) and one hitting the origin directly. When the public domain is down but the origin is up, you immediately know it's a Cloudflare issue. No time wasted debugging the origin.
The SRE / On-Call Engineer
Gets paged at 3 AM. Logs in and starts investigating. Spends 20 minutes checking the origin before realizing the origin is fine and the issue is Cloudflare's edge. By then, the outage has been going for 35 minutes without any customer communication.
The real cost: Night-time Cloudflare outages are the worst debugging experience. Everything looks healthy from the inside. The 20 minutes spent investigating the wrong layer is 20 minutes of downtime without a status update.
What they should have had: Separate monitors that distinguish the layers. Origin monitor is up + public monitor is down = Cloudflare issue. Both down = origin issue. The alert message itself tells the on-call engineer where to look.
Why Monitor Cloudflare?
Cloudflare sits between your users and your origin server. If Cloudflare has issues, your site becomes unreachable even if your server is perfectly healthy. DNS failures are especially impactful — your domain simply stops resolving.
What to Monitor
your-domain.comYour public domain (routed through Cloudflare)your-origin-server-ipYour origin server directly (to distinguish Cloudflare issues from origin issues)your-workers-endpoint.comCloudflare Workers endpoints (if applicable)What You Should Actually Do
- 1Monitor your domain through Cloudflare — the URL your users actually visit
- 2Monitor your origin server directly — bypassing Cloudflare to distinguish edge issues from origin issues
- 3Use a monitoring service that doesn't depend on Cloudflare — if your monitor also uses Cloudflare DNS, you might miss the outage
- 4Create a status page hosted independently — not behind the same Cloudflare zone as your app
- 5Bookmark cloudflarestatus.com — Cloudflare's official status page for global edge health
Cloudflare's Official Status Page
Cloudflare publishes real-time status at www.cloudflarestatus.com. Monitoristic doesn't replace this — it complements it. The official page tells you when Cloudflare reports an issue. Your own monitor tells you when your connection is affected, often before the status page updates. You also get push alerts instead of checking a webpage manually.
Cloudflare outages create a uniquely disorienting situation: your server is healthy, your code is correct, your database is responsive — but your users can't reach you. The fix isn't on your side. The only thing you control is how quickly you detect it, communicate it, and wait it out. Two monitors — one through Cloudflare, one direct to origin — tell you which layer failed in seconds instead of minutes.
Related Reading
Skip the panic. Know in 60 seconds.
Start Monitoring Cloudflare →Plans from $5/month · 14-day money-back guarantee