Sooner or later every uptime monitor meets a firewall. You turn on bot protection, tighten a rate limit, or move behind a CDN with a managed rule set, and the next morning your monitor reports a wall of 403s. The site is fine. Customers are buying things. The monitor is the only visitor being turned away.

That is a monitoring problem, not an outage. But it gets handled like an outage often enough that teams end up either muting the monitor or loosening their firewall to make the noise stop. Both are worse than understanding what the firewall is actually telling you.

Why firewalls block monitors

Bot protection exists to stop automated traffic, and an uptime check is automated traffic by design. Look at it from the firewall's side:

• It comes from a datacenter IP range, not a home or mobile network.
• It arrives on a fixed schedule, every 30 or 60 seconds, forever.
• It sends no cookies, has no session, and usually does not run JavaScript.
• It often hits the same URL from several countries at once.

Every one of those is a signal a bot score uses. So the firewall does its job and stops the request. Depending on the product and your settings, the monitor gets one of a few responses:

• A flat block. A 403 Forbidden or a branded "access denied" page. The request is refused, full stop.
• A rate limit. A 429 Too Many Requests, sometimes with a Retry-After header.
• An interactive challenge. A page that runs JavaScript, checks the browser, and maybe asks for a click before letting the visitor through. It often returns 403 or 503 while doing it.

None of these tell you whether your application is healthy. They tell you the edge is up and has an opinion about the visitor.

The trap: status codes look like failures

A naive check reads the status line, sees something that is not 2xx, and calls the site down. A 503 from a challenge page looks identical to a 503 from a crashed backend. A 403 from a bot rule looks identical to a 403 from broken auth middleware.

This is the same weakness we covered in your site can return 200 OK and still be down, in reverse. The status code is a thin signal. A healthy site can fail it and a broken site can pass it. To get a real answer, the monitor has to look at more than one number.

Firewall pages are usually easy to recognize once you look. They carry headers that name the provider, a request or ray ID, a challenge script, or a body with a recognizable block message. A monitor that reads those can classify the response as "blocked" instead of "broken," and that one distinction removes a whole category of 3am pages.

A block is a fact about the probe, not the site

Here is the mental model that makes this manageable: a block tells you about the relationship between one probe and your firewall. It says very little about the app behind it.

That is why where the block happens matters so much:

• One region blocked, others healthy. Almost always a reputation or geo rule. One probe's IP range got a bad score, or a country rule caught it. Your site is up. You might want to fix the rule, but nobody needs to wake up.
• Every region gets a challenge. Your edge is serving a challenge to all automated traffic. Real browsers solve it. Your monitor is now blind, which is worth fixing, but it is not evidence of an outage.
• Every region gets a flat block. Now it is worth paying attention. Maybe the firewall is blocking your monitors. Maybe a bad rule or a broken deploy is blocking everyone. From the outside you cannot tell the difference, and the cost of assuming it is fine is much higher than the cost of checking.

This is one more argument for checking from several places at once. With a single location, every block looks like the whole truth. With several, you can see whether the problem follows the probe or follows the site. We wrote more about that in multi-region monitoring explained.

How to stop the false alarms without weakening the firewall

You do not have to choose between bot protection and monitoring. A few practical steps cover most setups.

1. Give monitors a dedicated health endpoint

Point your uptime checks at a path built for them, like /health or /status, instead of your homepage. Then write a firewall rule that skips bot scoring on that one path. Keep it cheap and side-effect free so it is not worth abusing. If you are designing one from scratch, how to design a health check endpoint walks through what it should and should not check.

This keeps your full protection on the pages that matter to attackers and gives the monitor a clean lane on the page that matters to you.

2. Allowlist by something better than IP when you can

Monitoring providers publish their probe IPs, and allowlisting those works. It also drifts: providers add regions, IPs change, and the rule quietly stops matching. If your firewall supports it, match on a secret request header you set on the monitor instead. A header your firewall checks for is easier to rotate than a list of addresses and does not depend on anyone else's infrastructure staying still.

3. Keep rate limits above your check rate

A monitor checking every 30 seconds from five regions sends ten requests a minute to one path. That is nothing for most apps, but a strict per-path limit or a "same URL from many IPs" rule can catch it. Exempt the health path or raise the threshold for it.

4. Still monitor the real front door

The health endpoint tells you the app is alive. It does not tell you a visitor can get through. Keep a second, less sensitive check on your homepage or login page so you notice when the firewall itself starts blocking real people. That check is exactly the one most likely to hit a challenge, so it should be set up to treat a challenge as "blocked," not "down."

5. Watch for blocks after firewall changes

Most monitor blocks start the day someone changes a rule. When you tighten bot settings or enable a new managed rule set, check your monitors over the next hour. Catching it then is easier than diagnosing it from a confused alert a week later.

What a monitor should do with a block

Good monitoring treats firewall responses as their own category, not as failures:

1. Recognize the block. Read headers and body, not just the status code, so a challenge page is not mistaken for a crash.
2. Do not page on a challenge. A challenge means the edge is working and real browsers get through. The right signal is "your monitor cannot see past the firewall," which belongs on a dashboard, not a pager.
3. Degrade, do not fail, on a partial block. If some regions are blocked and others are healthy, the site is up. Mark the blocked regions as degraded so you can see them.
4. Escalate a unanimous flat block. If every region gets refused outright, open an incident. You would rather check and find a firewall rule than ignore it and find out it was everyone.

This is how Tallwatch handles it. Each check recognizes common firewall and bot-protection responses from the major providers. A bare 403 or 429, or a recognized block page, marks that region as degraded rather than down. An interactive challenge never opens an incident by itself, because real visitors pass it. A flat block only counts as down when every region is blocked. And because an incident only opens when several regions agree in the same round, one blocked region cannot page you on its own.

A quick checklist

• Health endpoint exists and is excluded from bot scoring.
• Monitors identify themselves with a header your firewall recognizes.
• Rate limits leave room for every region at your check interval.
• A separate check watches the public front door, tolerant of challenges.
• After any firewall change, someone looks at the monitors.
• Your monitoring tool treats a block as a block, and only pages when every region is refused.

A firewall that stops your monitor is doing its job. The goal is not to make it stop, but to make sure a stopped monitor never gets mistaken for a stopped site. If you want to see how the alerting side works once those signals are clean, the free plan includes multi-region consensus.