How to Monitor a Site Behind Cloudflare Without False Alarms: Rules, Headers, and Real Failures

Cloudflare will eventually block your uptime monitor. It looks like automated traffic because it is automated traffic, and a managed WAF rule, a bot fight setting, or a rate limit will start returning a challenge or a 1020 access denied to checks that ran fine for months. The result is an alert storm about an outage that never happened, on a site that is perfectly healthy behind an edge that is doing exactly what you configured it to do.

This article covers how to make Cloudflare let your monitor through without weakening protection for anyone else, which Cloudflare error codes represent real outages and which represent your own rules, and why monitoring the edge is not the same as monitoring your origin.

Why the monitor gets blocked

Cloudflare classifies traffic, and a request arriving from the same handful of addresses every sixty seconds with an identical fingerprint is exactly what its heuristics are built to catch. Several separate features can each independently decide to stop it. Managed WAF rulesets flag traffic matching known automation patterns. Bot fight mode challenges requests it judges non-human, and a monitor cannot solve a challenge. Rate limiting rules count requests per address over a window, and a frequent check from a small set of IPs can cross a threshold set for abusive traffic. Under attack mode challenges nearly everything by design.

The tell is in the response. A monitor receiving a 403 alongside a Cloudflare block page, or a 1020 access denied, has been stopped by a rule rather than by a broken server. Our breakdown of Cloudflare error 1020 covers how to trace a specific block back to the rule that caused it using the Ray ID in the security events log, which is the fastest way to find out which of the several possible features is responsible.

The fix: a skip rule on a secret header

The wrong fix is to allowlist the monitoring vendor's IP addresses and stop there. It works until the vendor adds a region, retires a range, or scales onto new infrastructure, and then it fails silently at the worst moment. IP lists are maintenance you will forget to do.

The right fix is a custom rule that skips security features for requests carrying a header only your monitor sends. Configure the check to send a header with a name and a long random value that nobody could guess, then create a WAF custom rule matching that header and set it to skip the managed rulesets, bot protection, and rate limiting. The header is effectively a shared secret, it survives any change to the vendor's infrastructure, and it grants no access to anyone who does not have it. Combine it with the IP list if you want defence in depth, but the header should be the thing doing the work.

Two refinements are worth adding. Scope the rule to the specific paths the monitor checks rather than the whole site, so a leaked header buys an attacker nothing interesting. And treat the header value like any other secret: rotate it on the same schedule as your other credentials, and do not paste it into a support ticket.

Which Cloudflare errors are real outages

Once the monitor is getting through, you need to read what it receives correctly, because Cloudflare generates its own 5xx codes and they mean different things from the ones your application generates. A 521 web server is down means the origin actively refused the connection. A 522 connection timed out means Cloudflare could not complete the TCP handshake with the origin at all. A 524 timeout occurred means the connection succeeded but the origin did not respond in time.

All three are real. They mean your origin is unreachable or too slow, and they deserve to wake somebody. A 1020, by contrast, means one of your own firewall or access rules matched the request, which is a configuration event rather than an outage. A 403 with a Cloudflare challenge page means the same. Configuring your alerting to treat 52x codes as incidents and 1020 responses as a rule problem is a small distinction that removes most of the noise from monitoring a Cloudflare-fronted site.

The edge is not the origin

There is a structural limitation worth understanding. A check hitting your domain reaches Cloudflare's edge, and Cloudflare will happily serve a cached response for a page whose origin has been dead for an hour. Your monitor sees a fast 200 and reports the site healthy, which it is, in the narrow sense that visitors requesting that cached page get it. Anything requiring the origin is broken, and your dashboard says nothing.

The complete picture needs two checks rather than one. The first hits your domain through Cloudflare and answers the question customers care about: can people reach the site. The second targets the origin directly, either at its address with a Host header set to your domain or at a dedicated origin hostname not proxied through Cloudflare, and answers the question your engineers care about: is the application actually running. When the first is green and the second is red, you are serving cache over a dead backend, which is a situation with a clock on it. That is the failure mode most Cloudflare-fronted monitoring setups cannot see, and it is worth the second check.

Common mistakes in monitoring behind Cloudflare

Allowlisting IP addresses only. Monitoring vendors change infrastructure. An IP list works until it silently does not, and the failure arrives as an alert storm rather than as a notice.

Skipping security for the whole site. A skip rule scoped to the paths your monitor actually checks limits the damage if the header ever leaks. Applying it site-wide turns a monitoring convenience into a hole.

Treating every 5xx as the same alert. Cloudflare's 521, 522, and 524 mean your origin is genuinely unreachable or slow. A 1020 means your own rule matched. Alerting identically on both guarantees noise.

Monitoring only through the edge. A cached response from Cloudflare can keep a monitor green while the origin is down. Without a second check against the origin, you find out when the cache expires.

Forgetting the rule after an incident. Teams that disable a WAF rule to unblock a monitor during an outage often leave it off. Put the skip rule back on the header and re-enable the protection.

FAQ

Why is Cloudflare blocking my uptime monitor?

Because the traffic looks automated. Managed WAF rules, bot fight mode, rate limiting, and under attack mode can each independently challenge or block a check that arrives from a fixed set of addresses on a fixed schedule.

What is the best way to allow a monitoring service through Cloudflare?

A WAF custom rule that skips security features for requests carrying a secret header your monitor sends. It survives infrastructure changes at the monitoring vendor in a way that IP allowlisting does not.

Does a 1020 error mean my site is down?

No. A 1020 means a firewall, WAF, or access rule on your own Cloudflare configuration matched the request and blocked it. The site is up and your rules stopped the check from reaching it.

Should I monitor the Cloudflare URL or my origin server?

Both. The proxied domain tells you what visitors experience, and a direct origin check tells you whether the application is actually running behind the cache. The gap between the two answers is where silent failures live.

Closing thought

Every false alarm from a Cloudflare-fronted site comes from the same root: the monitor and the edge disagree about whether the monitor is welcome. Settle that with a header rather than an address list, then teach your alerting the difference between an error Cloudflare generated about your origin and an error Cloudflare generated about your own rules. Those two changes remove nearly all the noise.

The remaining question is what a green check actually proves, and behind a cache the answer is less than most people assume. Odown supports custom headers on every check, asserts on response content rather than status alone, and runs from seventeen locations so you can watch the proxied domain and the origin side by side. If your Cloudflare setup has ever alerted you about an outage that was really a firewall rule, website monitoring starts at twelve dollars a month with a fourteen day trial.