Cloudflare uptime monitoring: health checks, origin monitoring, and the blind spots behind the proxy

Cloudflare uptime monitoring works, but it is not one thing. Cloudflare's own health checks run from its edge to your origin and start on the Pro plan, with 10 checks on Pro, 50 on Business and 1,000 on Enterprise. A third-party monitor sits outside Cloudflare and checks what visitors actually get. You want both, because each one is blind to the failures the other catches.

The reason this comes up at all is that Cloudflare sits between your users and your server, and anything in the middle can make a broken thing look healthy or a healthy thing look broken. Two specific traps catch teams repeatedly: a proxy that can answer while your origin is dead, and bot protection that challenges your monitor and logs it as a failure. Both are fixable once you know which one you have.

What Cloudflare health checks actually do

Cloudflare's standalone Health Checks are a service running on Cloudflare's edge that probes your origin server by IP address or hostname and notifies you when it stops responding. They are observability only. They watch, they alert, and they do not reroute traffic. That last part surprises people, because it is easy to confuse them with load balancer health monitors, which are a different product: those remove an unhealthy endpoint from the pool so traffic fails over. Load Balancing is a paid add-on with its own billing, starting around $5 a month.

They are included in the plan rather than sold separately, which is genuinely good value if you are already paying for Pro. Two limits are worth knowing before you rely on them. Cloudflare does not publish a minimum check interval per plan; the API default is 60 seconds, with a 5-second timeout and 2 retries, and the docs only warn that shortening the interval and adding regions increases load on your origin. And authenticated origin pull is not supported, so a locked-down origin needs a different arrangement.

You can run checks from between one and thirteen regions, and Cloudflare probes from three data centers in each region you pick. Selecting All Regions is limited to Business and Enterprise. The detail that matters for how fast you hear about an outage is the notification rule: an alert only fires after a status change in the majority of selected regions. With one region that is two of three data centers. With all thirteen it is seven of thirteen. That is a sensible way to avoid false alarms, and it is also a reason your alert may arrive later than you expect.

Why your monitor can say up while the site is broken

This is the claim you will see repeated everywhere: Cloudflare caches your pages, so an external monitor gets a cheerful 200 from the edge while your origin is on fire. It is true, but it is narrower than the internet suggests, and the details decide whether it applies to you.

Start with the good news. Cloudflare does not cache HTML or JSON by default. On a stock configuration, a monitor hitting your homepage is reaching your origin, so a dead origin shows up as a failure the way you would hope. The blind spot opens up in three specific situations.

The first is Always Online, which is available on every plan including Free. When Cloudflare cannot reach your origin at all, it serves a stale cached copy, or fetches static parts of your site from the Internet Archive if it has nothing cached. Crucially, and contrary to how it is usually described, Always Online does not trigger when your origin is reachable but returning errors. Cloudflare's documentation is explicit: a 500 or a 503 from a live origin does not activate it. It fires on the Cloudflare-generated 52x family, which means genuine unreachability.

The second is stale-if-error, and this is the one that actually masks a 5xx. The directive tells Cloudflare to serve cached stale content when the origin returns 500, 502, 503 or 504. Its cousin, stale-while-revalidate, serves stale content while refreshing in the background. If you have either in play, or the "serve stale content while revalidating" Cache Rule, an external monitor can be handed a perfectly good page while every real request behind it fails. One quirk worth writing down: if Always Online is enabled, both stale directives are ignored.

The third is Cache Everything. The moment you add a Cache Rule that makes HTML cacheable, an edge hit is served without contacting your origin at all, and a URL-and-status-code monitor is no longer testing your application. It is testing Cloudflare.

The practical answer to all three is to stop asserting on the status code alone. A check that also asserts on a value your application has to compute, such as a JSON field from a health endpoint, cannot be satisfied by a cached page. That is the whole argument for API monitoring with assertions rather than a bare HTTP ping.

The Cloudflare 5xx codes, and what each one blames

When Cloudflare cannot get a good answer from your origin, it generates its own error rather than passing one through. Knowing which code means "your server" and which means "your config" saves a lot of time at three in the morning.

You may still see error 527 referenced in old articles and even in a stray line of Cloudflare's own prose. Ignore it. It meant a Railgun listener failure, Railgun was deprecated on 31 January 2024, and the documentation page for the code no longer exists. If your monitoring runbook lists 527, that is a sign it has not been reviewed in two years.

Two of these deserve a monitoring rule of their own. A 525 or 526 means your origin certificate is the problem, which is the kind of failure that arrives on a schedule rather than at random. Certificate lifetimes are getting shorter every year, so SSL certificate monitoring on the origin, not just the edge, is worth setting up before you need it.

Cloudflare bot protection will challenge your uptime monitor

This is the failure mode that wastes the most time, because it looks exactly like an outage. Your monitor requests the page, Cloudflare decides an automated client is knocking, and returns a challenge. The documented status code for a Cloudflare block or challenge is 403, not 503, whatever older blog posts say. Your monitoring tool records a hard failure, you get paged, and the site is completely fine in a browser.

Here is the part that catches people out, and it is worth reading twice. Bot Fight Mode, the version available on the Free plan, cannot be bypassed with WAF custom rules or page rules. It does not run on the Ruleset Engine, so Skip, Bypass and Allow actions have no effect on it whatsoever. Cloudflare's own documentation names monitoring tools as an example of traffic you would want to except, and says the answer is to move to Super Bot Fight Mode, which comes with Pro and above and does honour Skip rules. The same bot machinery is what stops automated readers collecting page content at scale, which is why teams that genuinely need to read pages programmatically end up using a purpose-built web scraping API rather than fighting the challenge.

So your options, in order of preference:

• On Pro and above: create a WAF custom rule with the Skip action matching your monitor, and position it before the rule that blocks or challenges. This is the documented, supported method.
• On Free: an IP Access Rule is the only documented escape. Bot Fight Mode will not trigger if an IP Access rule matches the request first.
• Either way: if your monitoring tool publishes its check IP ranges, allowlist them. Cloudflare does not publish a health-check-specific IP list of its own; it publishes a general range list and a User-Agent string for its own probes.

There is also a cleaner way to tell a challenge apart from a real outage. Every Cloudflare challenge page carries a cf-mitigated: challenge response header, regardless of challenge type. If your monitor can assert on response headers, treat that header as "I am being challenged" rather than "the site is down". It beats guessing from a 403.

How to monitor the origin behind Cloudflare

Once you accept that edge checks and origin checks answer different questions, the setup is straightforward. Three approaches, with the trade-off attached to each.

Use Cloudflare Health Checks for the origin. They probe your origin directly, so the cache cannot hide a dead server from them. This is the cleanest option if you are on Pro or above. It tells you nothing about what visitors experience, because it never tests the path through the proxy.

Point an external monitor at the public hostname. This is the visitor's-eye view, and it is the only thing that catches a Cloudflare configuration mistake, an expired edge certificate, or Cloudflare itself having a bad day. Assert on page content or a JSON value, not just a 200, so caching cannot fake a pass.

Monitor the origin IP with a Host header. Standard practice, and it works, but be careful with the version of this advice that tells you to create a DNS-only subdomain pointing at your origin. A grey-clouded record does bypass the proxy, and Cloudflare is blunt about the cost: it publishes your real origin IP to anyone who queries it, which removes the protection you are paying Cloudflare for and lets an attacker skip the proxy entirely for your whole site. There is also a gotcha: if any A record on a name is proxied, Cloudflare treats all A records on that name as proxied, so it has to be a separate hostname. If you do it, lock the origin down to Cloudflare IP ranges plus your monitor's IPs.

What Cloudflare's own alerting will not tell you

Cloudflare used to advertise a feature called Passive Origin Monitoring, announced in 2019, which emailed you when it noticed your origin was unreachable with no configuration required. The name no longer appears anywhere in current Cloudflare documentation. The functional successor is the Origin Error Rate traffic alert, which watches for elevated 5xx responses and counts edge codes 521, 522 and 523 as origin errors.

It is a good feature with one caveat that matters enormously for smaller US businesses, and Cloudflare states it plainly: the approach does not work well for low traffic zones, because with few requests any single error can blow past the burn rate, and high sensitivity alerts are not recommended for quiet sites. If your site does a few thousand requests a day, traffic-rate alerting will either cry wolf or say nothing. A synthetic check that runs on a fixed schedule does not have that problem, because it generates its own traffic.

When Cloudflare itself is the outage

Worth planning for, because it has happened twice recently at scale. On 18 November 2025, Cloudflare's core proxy failed after a database permissions change caused a Bot Management feature file to exceed a hard size limit. Core traffic was affected from 11:20 UTC and restored at 14:30 UTC, with full resolution at 17:06. Customer sites returned 5xx errors, and Workers KV, Access, Turnstile and the Cloudflare dashboard were all hit. On 5 December 2025 a shorter incident, roughly 25 minutes, returned HTTP 500 for about 28% of Cloudflare's HTTP traffic after a configuration change triggered a bug in the legacy proxy.

The lesson is not that Cloudflare is unreliable. It is that a monitor living inside the same infrastructure as your site cannot tell you when that infrastructure is the problem. External monitoring from somewhere else entirely is the only thing that distinguishes "our app broke" from "our CDN broke", and that distinction changes what you write on your status page. Cloudflare publishes its own status at cloudflarestatus.com, which is worth having open before you start debugging your deploy.

This is also where multi-region confirmation earns its keep. A single-location check that fails during an edge incident tells you something is wrong but not where. Several regions agreeing that the site is unreachable, at the same moment Cloudflare's status page turns yellow, gives you the sentence you need for your customers. If you have not written those sentences yet, our incident communication templates cover what to post and when.

Common questions

Does Cloudflare have uptime monitoring?

Yes. Cloudflare's standalone Health Checks monitor your origin server from Cloudflare's edge and alert you when it goes unhealthy. They are included on Pro, Business and Enterprise plans, with 10, 50 and 1,000 checks respectively, and are not available on the Free plan. They monitor the origin only, not what your visitors experience through the proxy.

Can Cloudflare block my uptime monitor?

Yes, and it is common. Bot Fight Mode and the WAF can challenge an automated request, which returns HTTP 403 and looks like an outage to your monitoring tool. On Pro and above, add a WAF custom rule with the Skip action ahead of the blocking rule. On Free, Bot Fight Mode cannot be skipped by WAF rules at all, so an IP Access Rule is the only documented workaround.

Will Cloudflare's cache hide an outage from my monitor?

Sometimes. Cloudflare does not cache HTML by default, so a standard setup does reach your origin. The risk appears when Always Online is serving an archived copy of an unreachable site, when stale-if-error is serving cached pages during origin 5xx errors, or when a Cache Everything rule makes HTML cacheable. Assert on page content, not just the status code.

How often do Cloudflare health checks run?

The API default is every 60 seconds, with a 5-second timeout and 2 retries. Cloudflare does not publish a minimum interval per plan tier, and warns that shortening the interval while adding regions increases load on your origin. Third-party monitors typically offer faster fixed intervals, down to 30 seconds on mid-tier plans.

Should I monitor the Cloudflare edge or my origin server?

Both, because they fail differently. An origin check catches a dead application that the cache might otherwise mask. An external check on your public hostname catches DNS problems, edge certificate expiry, misapplied Cloudflare rules, and Cloudflare outages themselves. Running only one of the two leaves a category of failure you will find out about from a customer.

How many regions do Cloudflare health checks use?

You can select between one and thirteen regions, and Cloudflare probes from three data centers in each. All Regions is restricted to Business and Enterprise plans. Alerts fire only after a status change in the majority of selected regions, so two of three data centers for one region, or seven of thirteen if you select all of them.

A setup that covers both sides

If you want the short version, this is what a sound Cloudflare monitoring setup looks like. Turn on Cloudflare Health Checks against your origin if your plan includes them. Add an external monitor on the public hostname that asserts on content rather than status alone. Allowlist that monitor properly, with a Skip rule on Pro and above or an IP Access Rule on Free, and confirm it is not being challenged by checking for the cf-mitigated header. Monitor certificate expiry on the origin as well as the edge. Then make sure alerts require agreement from more than one location, so a single flaky network path does not wake anyone up.

None of that is exotic, and most of it is a one-time configuration. The reason it is worth doing deliberately is that every one of these failure modes produces a monitoring result that is confidently wrong, which is more expensive than no monitoring at all. If you are still choosing a tool for the external half, our comparison of uptime monitoring tools covers which ones support header and body assertions, and website monitoring explains how our own checks are put together.