Site Down but Working? Fix Monitor Blocks in Cloudflare

It's 07:40 and your phone buzzes: Bluegum Bakery is down. You open the site. It loads. You refresh the monitor and it's still red. Ten minutes later you're on a call with the client explaining that their website is, in fact, fine.

We look after a portfolio of client sites ourselves, and this is the false alarm we see most. It isn't a bug in the monitor. It's the site's own security doing its job a little too well. The good news is that it takes one rule to fix, once you know where to put it.

Why a working website can look "down"

An uptime monitor doesn't visit a site the way a person does. It sends a plain request from a server in a data centre, every few minutes, all day, and it doesn't run JavaScript or accept cookies. To a security system, that pattern looks a lot like a bot. Which, to be fair, it is.

The most common blockers we run into:

Cloudflare bot protection. Bot Fight Mode, Super Bot Fight Mode and "Under Attack" mode all challenge or block automated requests. Your browser passes the challenge; the monitor can't.
Server firewalls. CSF, Imunify360 and similar tools on cPanel servers block IP addresses that make "too many" requests, or that come from data-centre ranges.
WordPress security plugins. Wordfence, Sucuri and iThemes can rate-limit or block crawlers, and some block whole countries.
Country blocking. A client who blocked traffic from outside South Africa has also blocked any monitor that checks from Europe or the US.
Hosting-level protection. Some managed hosts run their own WAF in front of the server that you can't see from wp-admin.

All of them have the same effect. Real visitors get the page. The monitor gets turned away and, correctly from its point of view, reports that the site isn't serving.

Two paths compared: a request stopped by a firewall shield, and a server that is switched off

Blocked or down? A two-minute test

Before you change any settings, prove which one it is. Three quick checks will tell you.

1. Read what the monitor actually received

A good monitor shows you the response behind the red light, not just the colour. The status code tells most of the story:

What the monitor saw	What it usually means	Likely cause
`403 Forbidden`	Blocked, not broken	Bot rule, IP block or security plugin
`503` with a challenge page	Blocked, not broken	Cloudflare challenge or "Under Attack" mode
`429 Too Many Requests`	Rate limited	Firewall or plugin rate limit
Timeout, no response at all	Blocked or down	A firewall silently dropping the request, or a dead server
`500`, `502`, `504`	Genuinely in trouble	PHP error, crashed server, hosting outage

A 403 or a challenge page is the giveaway. A timeout needs the next two checks, because a firewall that drops requests instead of refusing them looks exactly like a server that's switched off.

2. Load the site from a different network

Turn off Wi-Fi on your phone and open the site on mobile data. If it loads, the site is up for the public. If your office network has been whitelisted on the client's firewall at some point, testing from the office proves nothing, so always use a network that's never been special.

3. Check the firewall's own log

This is where you find the proof. In Cloudflare, go to Security, Events and filter by the monitor's IP address. In Wordfence, check Firewall, Blocked or the Live Traffic view. In CSF, run csf -g followed by the IP address. If the monitor's requests are listed as blocked or challenged, you've found it, and you know exactly which layer to fix.

Fix 1: Allow the monitor in Cloudflare

If Cloudflare is the one blocking, the fix that works most reliably is an IP Access rule with the action Allow. Cloudflare's documentation says Bot Fight Mode won't act on a request that an IP Access rule has already matched. A WAF custom rule with a "Skip" action is not enough: Cloudflare states that Bot Fight Mode can't be bypassed that way.

Open the client's site in the Cloudflare dashboard.
Go to Security, WAF, Tools (in some accounts this sits under Security rules, and Cloudflare has been moving it around, so search the dashboard for "IP Access rules" if you can't see it).
Add the monitoring service's IP address, set the action to Allow, choose "This website" and add a note such as "Uptime monitor".
Repeat for every IP address your monitoring service lists.
Go back to Security, Events, wait for the next check, and confirm it now shows as allowed.

Two things to watch for. First, if "Under Attack" mode is switched on, every visitor gets a challenge and the monitor will never pass it; that mode is meant for minutes, not months, so switch it off once the attack is over. Second, Super Bot Fight Mode on paid plans has its own settings. If an Allow rule doesn't do it, set "Definitely automated" traffic to Allow while you investigate, then tighten it again.

200 Online's checks currently come from 46.101.205.31. If your monitor is a different service, use the IP list it publishes.

Fix 2: Allow it in the server firewall

If Cloudflare's Security Events show the request passing through, the block is on the server itself. On cPanel servers that's usually CSF or Imunify360.

CSF (ConfigServer Security & Firewall)

From SSH as root, or the CSF screen in WHM:

csf -a 46.101.205.31 "200 Online uptime monitor"
csf -r

The first line adds the address to csf.allow with a comment, and the second restarts the firewall so it takes effect. If the address was already blocked, remove the block too with csf -dr 46.101.205.31.

Imunify360

imunify360-agent whitelist ip add 46.101.205.31 --comment "200 Online uptime monitor"

Or, in WHM, open Imunify360, Firewall and add the address to the White List.

Shared hosting

On shared hosting you won't have access to the firewall. Send the host a short request (there's a template at the end of this guide). Most hosts will add an allow rule quickly if you give them the exact IP address and the reason.

Fix 3: Security plugins and rate limits

WordPress security plugins run inside the site, after Cloudflare and the server firewall, so they're the last place a request can be turned away.

Wordfence: go to Wordfence, Firewall, All Firewall Options and add the address to Allowlisted IP addresses that bypass all rules. Also check the Rate Limiting settings; "If a crawler's page views exceed" is a common culprit.
Sucuri firewall: in the Sucuri dashboard, open Settings, Access Control and whitelist the IP.
Country blocking: if the plugin blocks countries, either allow the monitor's IP explicitly or make sure the country the monitor checks from isn't blocked. 200 Online checks from Europe, so a "South Africa only" rule will block it unless the IP is allowed.

The mistake we see most: allowing it in the wrong place

Cloudflare and the server firewall are two completely separate gates. Allowing the monitor at the front gate does nothing if the back gate is the one refusing it, and the other way round.

We regularly see a client's developer add the monitor to Cloudflare, see no change, and conclude the monitor is broken, when the block was in Imunify360 all along. That's why step 3 of the two-minute test matters. The log tells you which gate to open. Don't guess.

The same goes for proxying. If a site is behind Cloudflare, the server firewall sees Cloudflare's IP addresses, not the monitor's. In that case a server-side block of the monitor usually comes from a rule that reads the original visitor IP header, and allowing the monitor's IP on the server is still the right fix.

Two separate gates, Cloudflare in front and the server firewall behind it, with the monitor stopped at the second gate

An email you can send to your client's host

Copy, paste and fill in the blanks:

Hi there,

We monitor uptime for [website address] on behalf of [client name]. Our monitoring checks are being blocked by the server's firewall, so the site is reported as offline while it's working normally for visitors.

Please could you add the following IP address to the firewall's allow list for this account: 46.101.205.31 (200 Online uptime monitoring). It makes one request every few minutes to the homepage only.

Thanks very much,
[your name and agency]

Keep it fixed

An allow rule is a set-and-forget fix, until someone changes the firewall. Three habits keep the false alarms away:

Add the monitor's IP to your onboarding checklist for every new client site, before you switch on alerts.
Note it in the client's credentials or site notes, so whoever touches the firewall next knows why the rule is there.
Turn off client alerts for sites you can't fix yet. A client who gets three "your site is down" emails for a site that's up will stop trusting the fourth, which might be real.

Once the rule is in place, a red light means something again. And that's the whole point of monitoring.

Frequently asked questions

Why does my website show as down when it is working?

Usually a firewall, Cloudflare security setting or security plugin is blocking the monitoring service's requests while letting ordinary visitors through. The monitor sees a 403, a challenge page or a timeout and reports the site as down.

Is it safe to allow an uptime monitor's IP address?

Yes, as long as you allow only the exact addresses your monitoring service publishes. An allow rule lets that one address skip security checks; it doesn't open anything else on the server.

Should I whitelist the monitor in Cloudflare or on the server?

Wherever the block is happening. If Cloudflare shows the request as blocked in its Security Events, allow it in Cloudflare. If Cloudflare passed it but the server refused it, allow it in the server firewall or security plugin. Sometimes it is both.

Why does my monitor get a 403 Forbidden error?

A 403 means the server or a security layer in front of it understood the request and refused it. For a monitor that almost always means a bot or IP rule, not a broken website.