Let the CoreDash Uptime Checker Through Your Firewall

How the uptime checker identifies itself

Every uptime check comes from one of two IP addresses, with a fixed user agent:

51.195.222.219
51.195.222.220

CoreDash-Uptime/1.0 (+https://www.coredash.app/uptime)

The addresses don't change, so allow by IP. That is different from the CoreDash performance tester, which runs from cloud infrastructure and has to be allowed by user agent.

How you see that it is blocked

A monitor whose checks get a 403, a 429 or a Cloudflare challenge shows Blocked, in amber. Blocked never counts as downtime. Your visitors still get the page; the firewall stops the checker, and the monitor can't tell whether the site is up.

Cloudflare

On a Pro plan or higher, add a WAF custom rule with the Skip action:

1. Go to Security > Security rules and create a custom rule. Name it CoreDash uptime.
2. Click Edit expression and enter (ip.src in {51.195.222.219 51.195.222.220}).
3. Set the action to Skip.
4. In the Skip options, check Super Bot Fight Mode. Check All managed rules too if a managed rule blocked the check.
5. Deploy the rule and put it above your other custom rules.

On the Free plan, Bot Fight Mode does not run through the WAF, so a Skip rule can't touch it. With Bot Fight Mode on, the checker stays blocked. Turn it off under Security > Bots, or accept Blocked for that monitor.

Skip on a header instead of an IP

You can also let the checker through on a request header. In CoreDash, edit the monitor, open Advanced and add a header, for example X-CoreDash-Uptime with a long random value. The checker sends it with every check. In Cloudflare, use this expression:

any(http.request.headers["x-coredash-uptime"][*] eq "your-random-value")

Cloudflare lowercases header names, so the name in the expression is lowercase whatever you typed in CoreDash. Anyone who knows the value gets past the rule, so treat it like a password and don't reuse it elsewhere. It is the same approach as the request headers for CoreDash traces.

Wordfence

Go to Wordfence > Firewall > All Firewall Options. Under Advanced Firewall Options, add both addresses to Allowlisted IP addresses that bypass all rules, one per line, and save.

If your site sits behind Cloudflare, check that Wordfence sees the real visitor IP. Without it, every request looks like it comes from Cloudflare and the allowlist never matches. The setting is How does Wordfence get IPs under the general options.

The origin check

The origin check connects to your server directly, so it has to get past the firewall of the server itself. Many origins behind Cloudflare only accept Cloudflare's IP ranges, which Cloudflare recommends. Then the origin check gets a connect timeout on its first try, while the edge check is fine.

Add both checker addresses to the server firewall. With ufw:

sudo ufw allow from 51.195.222.219 to any port 443 proto tcp
sudo ufw allow from 51.195.222.220 to any port 443 proto tcp

With an nginx allowlist, put them above the deny all; line:

allow 51.195.222.219;
allow 51.195.222.220;

Still blocked?

Then the block comes from another layer: a second WAF, a security plugin, a rule in .htaccess or a rate limit at your host. The checks table on the monitor page shows the status the checker got. If you can't find the rule, contact us with the firewall you use and the monitor's URL.