A 403 that comes back in 19 milliseconds is not an outage. DNS resolved. TCP connected. TLS completed. Your origin then composed a refusal and sent it. Every one of those steps is evidence the server is running fine and simply doesn’t like the client asking.
Plenty of monitoring tools record that as downtime anyway. Then your uptime percentage drops for a week nothing was actually wrong.
Is It You or Them?
Two very different things produce a “down” alert on a site you can load in your own browser.
A transient network fault between one probe location and your origin. One region’s route flaps, that check fails, everything else is fine. This is the classic false positive, and the fix is consensus rather than configuration.
A deliberate refusal by a firewall, WAF, CDN, or bot-management service. Nothing is broken. A rule decided your monitor looks like a bot, which, to be fair, it is. No amount of checking from more places will help, because every location gets refused identically.
Telling them apart takes about a minute, and the status code does most of the work.
The Fastest Diagnosis
Run the same request your monitor runs and read the response, not the page.
curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/the-exact-path-monitored
Then interpret:
- A 403, 401, or 407 in well under a second. You are being refused, not failing. Something in front of the origin made a policy decision.
- A 429. Rate limiting. Often self-inflicted by monitoring itself, especially if several regions check the same host in the same second.
- A 451. A geo or legal block. Availability is not the issue.
- A 418. Non-standard, but used in the wild as a bot refusal, notably by Akamai deployments.
- A connection timeout, refused connection, or 5xx. Now you may have a real problem. Read the difference between 502, 503, and 504, because they point at different layers.
The tell is speed as much as code. Real outages tend to be slow or silent; a bot wall answers instantly, because refusing is cheap.
If curl from your laptop succeeds while the monitor fails, that is not proof the monitor is wrong. Your laptop has a residential IP, a browser user agent, and probably a warm session. The monitor has none of those, which is exactly what the bot rule is keying on.
You can close most of that gap in one command. Send the request as the prober identifies itself, and you will usually reproduce an uptime monitor blocked by firewall rules on the first try:
curl -sS -o /dev/null -w "%{http_code}\n" \
-A "Uptime-Monitor/1.0" https://example.com/the-exact-path-monitored
A 200 from your browser and a 403 from that command is a confirmed diagnosis: the rule is matching on user agent, and the fix is an allowlist entry rather than anything on your server. If both come back 200, the refusal is keyed on something else, most likely source IP or a datacentre ASN reputation list.
What Blocked Should Mean to Your Monitoring Tool
This is the part worth being opinionated about. A refusal is not an outage, and a monitoring product that scores it as one is publishing a number it knows to be wrong.
FlareWarden treats the whole refusal family (401, 403, 407, 418, 429, and 451) as a distinct verdict called blocked. Those checks are excluded from your uptime figure, they never fire a downtime alert, and cross-region validators read them as evidence the origin is alive rather than as confirmation of an outage. If every region gets refused, the monitor surfaces a Limited monitoring banner instead: the site is clearly serving traffic, we just can’t verify it any more. Saying so plainly beats inventing a number.
One deliberate subtlety. Only the stable refusals (401, 403, 407, 451) promote a monitor to that limited state. A 429 or a 418 still counts as blocked for the individual check, but never escalates, because our own multi-region fan-out can provoke a rate limit by probing one host from many places at once. Treating a throttle we caused as proof your site is permanently uncheckable would be its own kind of false alarm.
This is the failure mode that consensus can’t solve, which is the honest limit named in our piece on false positive downtime alerts. Agreement between regions is powerful against network flakiness and useless against a policy that refuses all of them.
Fixing It Properly
Allowlisting by user agent is the quickest route, and for most people it is enough. FlareWarden probes identify themselves honestly:
Uptime-Monitor/1.0
Uptime-Monitor-Content/1.0
Uptime-Monitor-Dependency/1.0
Allow those strings in your WAF or bot-management rules and the refusals usually stop.
Allowlisting by IP is the stricter option. Our probes use static egress addresses, one per city, published as the canonical list on the probe IPs and allowlisting page. Two things save you work there. First, you only need the rows for the region your monitor runs in, since a monitor in EU West is never probed from Singapore. Second, those addresses are stable across infrastructure changes on our side, so this is not a list you will be chasing every quarter.
Three practical notes, learned the boring way:
- Scope the rule to the path you monitor, not the whole site. A global allow rule is a bigger hole than you need, and reviewers hate it.
- If a vendor runs your edge, you may not own the rule. Send Cloudflare, Akamai, DataDome, or your host the probe IP page and ask them to allow the monitoring probes explicitly.
- Re-check after any WAF change. Bot rules get retuned, and a rule that stops matching is silent. The monitor going from blocked back to green is the signal you want.
How to Know First Next Time
The reason this matters beyond one bad week: a blocked monitor is not just a wrong number, it is a monitor that has quietly stopped working. If your tool scores refusals as downtime, you get noise. If it scores them as uptime, you get worse than noise, because a genuine outage behind a bot wall now looks identical to a healthy block.
Either way you want to be told. Watch for a monitor whose failures are all the same status code and all suspiciously fast, treat any limited-coverage warning as a to-do rather than a cosmetic badge, and when you are honestly unsure whether an outage is real, check the site from outside your own network before you start restarting things.
Key Takeaways
- A refusal is not an outage. 401, 403, 407, 418, 429, and 451 all prove the origin answered, which means DNS, TCP, and TLS all worked.
- Speed is the tell. Bot walls refuse in milliseconds; real failures are slow or silent.
- Consensus doesn’t help here. Checking from more regions fixes network flakiness, not a policy that refuses every region equally.
- Allowlist by user agent first, by static probe IP if your rules demand it, and scope the rule to the monitored path.
- A blocked monitor has stopped working, even though nothing looks red. Treat limited coverage as an outage of your monitoring, not a cosmetic warning.
Tired of uptime numbers that count bot challenges as downtime? Start monitoring free with FlareWarden — 15 monitors, cross-region checks, and refusals scored honestly rather than as fake outages.