If you put a client site behind Cloudflare and then point an uptime monitor at it, sooner or later you will get an alert that says the site is down while the site is, in fact, fine. What the monitor received was a 403 from the WAF, a 503 with a “Checking your browser” page, or a JavaScript challenge that a plain HTTP client cannot solve.
This guide shows how to let a monitor through Cloudflare’s WAF while keeping the protection on for everyone else. The examples use Tenium’s checker, but the shape of the rule works for any monitor that sends a fixed User-Agent and lets you add a custom header.
Why Cloudflare blocks monitors
Cloudflare’s Bot Fight Mode, Super Bot Fight Mode and managed WAF rules score requests on signals like TLS fingerprint, request headers and request rate. A monitor is, by design, an automated client that hits the same URL from the same IPs every 30 seconds. It looks exactly like what those rules exist to stop.
Three things typically happen:
- Managed Challenge (HTTP 403 or 503). The monitor gets an HTML page asking it to run JavaScript. It cannot, so it reports a failure.
- Rate limiting (HTTP 429). Each live region checking every 30 seconds sends 2 requests a minute, so a monitor that uses all 2 of our regions (Amsterdam and London) sends about 4 requests a minute to one path. A strict rate-limit rule can trip.
- Country or ASN blocks. If you block traffic from outside your market, a checker in New York is blocked too.
None of these mean your site is down. They mean the monitor is being treated as a visitor instead of as a tool.
The wrong fix: allow the User-Agent only
The obvious fix is a WAF skip rule that matches the User-Agent. Tenium sends Tenium-Monitor/1.0 (+https://tenium.app/bots) on every request. A rule like http.user_agent contains "Tenium-Monitor/1.0" with the action Skip will let checks through.
The problem is that anyone can send that header. If the rule skips all WAF components, you have handed out a bypass to every scraper that reads this blog post. Do not do this on its own.
The right fix: User-Agent plus a secret header
Tenium lets you add custom request headers to any monitor on Pro and above. Add one called x-tenium-secret with a long random value, then write a WAF rule that requires both the User-Agent and the secret.
In the Cloudflare dashboard, go to Security → WAF → Custom rules → Create rule, switch to the expression editor and paste:
(http.user_agent contains "Tenium-Monitor/1.0") and (http.request.headers["x-tenium-secret"][0] eq "YOUR_SECRET")Set the action to Skip and tick the components you want skipped: at minimum All managed rules and Rate limiting rules. Also tick Bot Fight Mode if your plan shows it. Leave “Log matching requests” on so you can confirm the rule fires.
Replace YOUR_SECRET with the same value you typed into the monitor’s custom header. Something like the output of openssl rand -hex 24 is fine. Rotate it if you ever suspect it leaked; the rule and the monitor header are the only two places it lives.
The [0] index is required. Cloudflare exposes request headers as arrays because a header can appear more than once, and eq compares a single string.
If you have Super Bot Fight Mode on a Pro or Business plan
Super Bot Fight Mode is evaluated before custom rules in some configurations and it does not honour skip rules for “definitely automated” traffic. If checks still fail after adding the rule, go to Security → Bots and either set “Definitely automated” to Allow, or turn on Allow verified bots. Tenium is not in Cloudflare’s verified bot list, so the first option is the one that helps.
Should you allow-list IPs instead?
You can. Tenium publishes its checker IPs at /checker-ips, with a JSON feed you can pull into automation. An IP allow rule looks like:
(ip.src in {164.92.217.216})IP rules are stronger than a header, but they go stale when the monitoring provider adds a region. The header-plus-secret approach survives IP changes, and the IP list is a good second factor if you want both. Combine them with and for the strictest setup.
Checking that it works
After saving the rule, open the monitor in Tenium and click Check now. The result card shows the status code from each region. If every region shows 200, you are done. If one region still shows a challenge page, check whether that region’s country is blocked by a separate rule, and whether the rule order puts a block ahead of your skip.
In Cloudflare, Security → Events filtered by the rule name shows every matching request with the action taken. You should see “Skip” entries arriving every 30 seconds from the checker IPs.
Keep the monitor honest
Skipping the WAF for your monitor means the monitor sees the site the way the origin serves it, not the way a challenged visitor does. That is what you want for uptime. If you also want to know when Cloudflare itself is challenging real visitors, add a second monitor without the secret header and set its expected status to anything but 403 and 503. When that one fires and the first does not, the problem is Cloudflare, not the origin.
Full details, including the equivalent rules for Wordfence and Sucuri, are in the Cloudflare docs page.
Related
The checks you are letting through are described under website monitoring and API monitoring. The HTTP headers tool shows exactly what a Cloudflare-fronted URL returns, and multi-location checks explains why a challenge in one region can look like an outage. Comparing vendors on how they handle WAFs? Start at the comparison hub.
Related
Related Tenium pages
Monitor your first site free
30 monitors free, checks from 2 regions, no card. SSL and domain expiry from $7 a month.