Monitor a site behind Cloudflare without false alarms

Yağız Yorulmazlar — Sun, 15 Nov 2026 07:50:05 +0000

I build You Up?, an uptime monitoring service, so this guide comes from that work. It was first published on uup.dev.

Use a monitor that your bot filter can recognize, and that confirms a failure before it alerts you. Every request You Up? sends is signed, and Cloudflare lists our probe as a verified bot, so it can tell our checks from the bots it is there to stop. When a check still fails, other locations look before you hear anything. Allowing our addresses by hand is only the fallback.

Why monitors get blocked

A bot filter is there to stop automated traffic, and an uptime check is automated traffic. It comes from a server, on a fixed schedule, and it runs no JavaScript. To a filter that does not know it, it looks like the bots the filter was put there to stop. So the filter answers it with something other than your page:

A refusal. Cloudflare's error 1020, Access denied, means that a security feature the site's owner set up blocked the request. (developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1020, checked 13 November 2026) Cloudflare sends error 1020 with the HTTP status 403. (developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1020, checked 13 November 2026)
A challenge: a page that asks the visitor to prove it is a person, which a monitor cannot do. When Cloudflare answers with a challenge in place of the page, its response carries the header cf-mitigated, set to challenge. (developers.cloudflare.com/cloudflare-challenges/challenge-types/challenge-pages/detect-response, checked 13 November 2026)
A rate limit, when checks from several places add up.

None of these is your page, so a monitor that cannot tell them apart says your site is down. Your visitors see nothing wrong. That is a false alarm, and your server did nothing to cause it.

What the usual workarounds cost

The usual advice is to let the monitor through by hand. Better Stack's guide for sites behind Cloudflare advises allowing its addresses and its User-Agent. (betterstack.com/community/questions/whitelisting-better-stack-ip-cloudflare, checked 13 November 2026) Each way of doing it costs you something:

Allowing the monitor’s addresses. It works, but the list is yours to keep current. When the monitor adds or replaces a server, checks from the new address are blocked until you add it, and you hear about that as an outage.
Allowing its User-Agent or a header. Anybody can copy a header. A rule that lets through every request that carries it lets through anybody who sends it, the bots you wanted to stop included.
Turning the bot filter off. That trades a false alarm for real bot traffic.

How You Up? gets through

Every request is signed. Our probe signs each request with Web Bot Auth, an open method, being standardized at the IETF, that lets a server or a bot filter check that a request came from the bot it names. A header can be copied; a signature that checks cannot be made by anybody else. Cloudflare uses Web Bot Auth, a signature on each request, to verify bots. (developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth, checked 13 November 2026)

Cloudflare verifies the probe. The You Up? probe is a Cloudflare verified bot: see its entry in Cloudflare Radar’s bots directory. Cloudflare can tell our checks from the bots its rules are there to stop, without a list of addresses from you.

A failure is confirmed before you hear about it. When a check fails, the location that saw it tries again a few seconds later. When that fails too, the Monitor’s other locations look at once. You get an alert only when the failure is confirmed from other locations, so a filter that turns away one location now and then does not wake you. See alerts only for a real outage.

You see who answered. When only one location gets a refusal, the Monitor says so, and links the steps to let our checks through. When a failure is confirmed, the alert says where the request stopped, and names a service such as Cloudflare when it answered in place of your server. You can tell a refusal from a site that is down.

Free watches from one location

Free watches from one location, so it has no other location to ask. It still tries again before it tells you, so one turned-away request does not wake you, but a filter that keeps turning that location away can. Every paid Plan watches from five locations, and confirms each failure from the others.

If your rules still block us

A rule of your own can still turn our checks away, and not every bot filter checks signatures yet. A rule that turns away every location is confirmed like any other failure, so it does need fixing. Then allowing our checks is the fallback:

Allow requests from the addresses on our probe’s page, the IPv6 ones as well as the IPv4 ones.
Skip bot checks and rate limits for them.
Watch your Monitor’s next checks. They show whether every location gets through.

The steps for each service, on the probe’s page, show where this is done in Cloudflare, Akamai, DataDome, AWS WAF, Vercel and the other tools sites use most, and in nginx and Apache. When an address of ours is added or replaced, that page changes first. A script that keeps an allowlist current can read the same addresses as plain text.

Cloudflare's Bot Fight Mode cannot be bypassed or skipped by custom rules. (developers.cloudflare.com/bots/get-started/bot-fight-mode, checked 13 November 2026) If it turns our checks away, see the Cloudflare steps.

Allow our probe, in the Docs

Questions

Do I need to allow your addresses before I start?

No. Add a Monitor and watch its first checks. If every location gets through, you need no rule. If a location gets a refusal or a challenge, follow the steps on our probe’s page.

What does a check send?

A User-Agent that contains uup/1.0 and links to our probe’s page, an X-Uup-Check header that names the check, and the three headers of the signature. A server that ignores the signature works as it did before. Nothing else about the request changes.

Is You Up? the only monitor that signs its requests?

No. Uptime.com publishes a Web Bot Auth key directory too. (uptime.com/.well-known/http-message-signatures-directory, checked 13 November 2026) Web Bot Auth is an open method, and any monitor can sign with it.

What if my firewall is not Cloudflare?

The signature works the same way for any server or bot filter that checks it. For one that does not check it yet, our probe’s page has steps for each service.

DEV Community: Yağız Yorulmazlar