Cloudflare Health Check Setup and Its Blind Spot

A Cloudflare health check is a probe that runs on Cloudflare's edge network and reports whether your origin server is answering. It comes in two flavours that people constantly confuse: Standalone Health Checks, which just watch and notify, and Load Balancing monitors, which take an unhealthy pool out of rotation.

Which of the two do you want?

Standalone Health Checks watch an origin and tell you about it. Cloudflare's own documentation describes them as a way to see origin health even when you have a single origin and no traffic to balance. Load Balancing monitors do the same probing, then act on the result.

	Standalone Health Checks	Load Balancing monitors
What it does with a failure	Notifies you	Removes the pool from rotation
Needs Load Balancing	No	Yes
Plan availability	Pro and above	Load Balancing subscription
Checks included	10 on Pro, 50 on Business, 1,000 on Enterprise	Per pool
Regions	1 to 13, three data centers each	Three probes per selected region

Those plan numbers come from the availability table on Cloudflare's docs page as of September 2026, where the Free tier is listed as having no Standalone Health Checks at all. The feature is now sold as part of Smart Shield.

How to set up a Cloudflare health check

The dashboard route takes about two minutes. Everything below is also available through the API and the cloudflare_healthcheck Terraform resource, which is worth using if you have more than a handful.

1. Open Traffic, then Health Checks on the zone you want to watch, and select Create.

2. Point it at the origin, not the proxied hostname. The check is meant to reach past the edge to the server behind it.

3. Set the path and the expected codes. A dedicated endpoint like /healthz beats the homepage, because the homepage drags in a database and a template render.

4. Add a response body substring. Cloudflare looks for it in the first 10 KB of the body, so put the marker near the top of the response.

5. Choose the interval and the check regions. Both multiply origin load, since each selected region probes from three separate data centers.

6. Set retries. These are attempts made after a timeout before the origin is marked unhealthy, and they are your main defence against a single dropped packet paging someone.

7. Save and deploy, then wire a notification to whichever channel your on-call actually reads.

Choosing regions and interval without hammering your origin

Cloudflare's regions page is explicit that checks do not run from every data center. You choose between one and thirteen regions, and three data centers probe from each one. Pick four regions on a 60-second interval and your origin sees a request roughly every five seconds, all day long.

Analytics come back as regional aggregates and one global aggregate. Per-data-center detail is not exposed, so a single sick data center inside a region shows up as a partial failure that you cannot pin down further.

The load balancer variant applies a majority rule on top. The monitors documentation explains that a region counts as healthy when most of its data centers pass, and an endpoint counts as healthy when most regions pass. All Regions means 13 regions and 39 probes, and it is Enterprise only as of September 2026.

What does the edge view miss?

It answers one question well: can Cloudflare reach your origin. It cannot answer the question your customers care about, which is whether a browser can load your site through Cloudflare.

Every failure that lives in front of the origin is invisible to it. A proxy status toggled off. A WAF rule that starts matching legitimate traffic. A redirect loop, a DNS record edited during a migration, an expired certificate on a custom hostname, or an incident on the edge network itself. In each case the origin is fine, the check is green, and the site is broken for real people.

Authenticated origin pull is not supported by Standalone Health Checks either, so an origin locked to Cloudflare client certificates needs a separate path for the probe to use.

Adding a check from outside the network

The fix is boring: check the public hostname from somewhere Cloudflare does not operate. In our testing that is the pairing that catches the most, because the two probes fail in different situations rather than the same one.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "public site through cloudflare",
    "type": "keyword",
    "target": "https://example.com/",
    "intervalSec": 60,
    "regions": ["los-angeles", "london", "singapore"],
    "keyword": "Sign in",
    "keywordMatch": "contains",
    "expectedStatus": [200]
  }'

The keyword assertion is doing real work there. Cloudflare's own error pages return a 5xx with a branded body, which a status-code check catches easily. A misrouted origin is the harder case, because it can return a cheerful 200 with the wrong site inside it. Only a body check notices that, and the pattern is covered in more depth under keyword monitoring.

Run it from several places so one bad path does not read as an outage. Six probe regions are available as of September 2026, and if your firewall rules are tight the egress addresses are published on the probe IPs page.

Common mistakes

Pointing the health check at the proxied hostname. You then measure Cloudflare checking Cloudflare, and a cached response can keep the check green after the origin has died. Use the origin address.

Treating a green dashboard as proof the site works. The edge probe and the customer take different paths. Confirming from outside is the same idea as blackbox monitoring, applied to a network you do not own.

Turning the interval down without counting the multiplier. Three data centers per region, times your region count, times your frequency. A 10-second interval across six regions is eighteen requests every ten seconds against one origin.

A Cloudflare health check is the right tool for knowing your origin is alive behind the proxy, and it is the wrong tool for knowing your customers can reach you. Run both: the edge probe for origin health, and an outside check on the public hostname for everything in between. You can put the second one together on the free plan, which allows 10 monitors as of September 2026, and open an account before your next DNS change.