Why Cloudflare can make your uptime monitor lie to you

A monitor that says your site is down is not always right. If your site sits behind Cloudflare, a "down" alert can mean two things that have nothing to do with your server: Cloudflare is blocking your monitoring tool specifically, or Cloudflare itself is having an outage. In both cases your real visitors may be seeing the site just fine.

This is not a rare edge case worth a footnote. A monitor that cries wolf trains you to distrust its alerts, and the next real outage gets a slower response because the last three "down" alerts turned out to be nothing. Knowing which of these three situations you are looking at, a Cloudflare block, a Cloudflare outage, or a real problem on your own server, is what keeps the alert worth reacting to.

Cloudflare is blocking your monitoring bot, not your visitors

Cloudflare’s security layer scores every incoming request, and automated monitoring checks look a lot like the traffic it is built to catch: no browser fingerprint, a repetitive request pattern, no time spent rendering a page. The settings most often responsible are Bot Fight Mode, Super Bot Fight Mode, and the general Security Level setting, all of which score requests for how human they look and act on the ones that score poorly. When Cloudflare decides a request looks automated, it can respond in three ways instead of passing the request to your server:

• A challenge page: a JavaScript check, managed challenge, or CAPTCHA instead of your actual page. A plain HTTP client cannot solve it, so the check reads it as a broken response.
• A hard block: a 403 Forbidden served directly by Cloudflare, based on a WAF rule or an IP reputation score.
• Rate limiting: a 429 Too Many Requests response if your monitor checks more often than a Cloudflare rule allows.

All three produce the same outcome for your monitor: an unexpected response instead of your real page, read as downtime. The fastest way to confirm this is happening is the cf-mitigated response header, which Cloudflare adds only when it intervened before your server ever saw the request:

curl -sI https://example.com | grep -i cf-mitigated
# cf-mitigated: challenge

A response with that header present means Cloudflare answered on your server’s behalf. No header at all, paired with a real error, points somewhere else. Cloudflare’s Security Events log shows the same thing from the dashboard side, with a timestamp you can match against your monitor’s alert.

Cloudflare itself might be the one that is down

The second case is simpler and has nothing to do with your configuration at all: Cloudflare, as a company running infrastructure at a massive scale, has its own outages. When that happens, requests to every site behind the affected part of Cloudflare’s network can fail, including yours, and there is nothing you did wrong. The fastest check is Cloudflare’s own status page, cloudflarestatus.com, which reports incidents as they happen. If it shows a live incident matching your alert’s timing, the problem is not your server and not your monitor.

Three ways to stop this from happening again

Only one of these fixes both problems at once. The other two only help with the first.

• IP allowlist: if your monitoring tool publishes a static list of IP addresses it checks from, add a Cloudflare WAF rule that skips security checks for requests from those IPs. This only works if your monitoring tool actually commits to stable IPs, not every tool does.
• Secret header plus a WAF skip rule: if your monitoring tool lets you attach a custom header to every request, like WebPixie does, set it to a value only you know, then add a Cloudflare rule that skips security checks when that header and value are present. This avoids depending on IP addresses staying the same.
• Monitor the origin directly: point your monitor at your server’s actual IP address instead of your domain, with the HTTP Host header still set to your domain so the server knows which site to serve. This request never touches Cloudflare at all, so it is unaffected by both a bot-blocking rule and a Cloudflare-side outage. The tradeoff is that it also will not tell you if Cloudflare itself is unreachable for your real visitors, only that your own server is fine.

That last point is why the direct-origin check works best as a second monitor running alongside your normal one, not a replacement for it. When the two disagree, that disagreement is the diagnosis: origin up but the regular check down points at Cloudflare, either blocking your bot or having its own problem, not your server. When they agree, both down, that agreement is worth just as much: it means the problem survives even a request that never touched Cloudflare’s security layer, which puts the origin server itself back on the list of suspects.