How to allow Uptimecheck through a firewall

A firewall, a CDN’s bot protection or a security plugin can block our checks while real visitors get through. The monitor then reports an outage that isn’t one, usually HTTP 403, HTTP 429 or a timeout. Allow our checks once and it stops.

Where checks come from

• Stockholm, Sweden: 95.111.205.91 and, over IPv6, 2a04:3541:8000:1000::/64
• London, United Kingdom: 94.237.50.166 and, over IPv6, 2a04:3541:1000:500::/64
• New York, United States: 209.94.56.204 and, over IPv6, 2605:7380:8000:1000::/64

When we add a location, its address is added to this list, so look here again when a new location appears under Locations in a monitor’s form. A monitor without chosen locations is checked from every location that is online, so a new one starts checking it right away.

Website, port and ping checks, re-checks and traceroutes come from all of these addresses. Multi-step flows, site health scans, Test request in the monitor form and webhook alerts come from Stockholm only. If your site has an IPv6 address (an AAAA record), checks may arrive over IPv6 from any address in the IPv6 ranges above, so allow the whole ranges, not single addresses.

User agents

• Website and API checks and flows: Uptimecheck/1.0 (+https://uptimecheck.com). A User-Agent you add under Request headers replaces it.
• Site health scans: Mozilla/5.0 (compatible; UptimecheckBot/1.0; +https://uptimecheck.com/bot).
• Test request in the form: Uptimecheck/1.0 (+https://uptimecheck.com; test run). Webhook alerts: Uptimecheck-Alerts/1.0.
• Flows with Run in a real browser and incident screenshots run in Cloudflare’s network, not from the addresses above. Their user agents contain Uptimecheck/1.0.
• Page speed is measured by Google PageSpeed Insights, so those requests come from Google, with a user agent that contains Chrome-Lighthouse.

All of ours contain Uptimecheck. Anyone can send a user agent, so allow by address where you can.

Cloudflare

If your site is behind Cloudflare, allow us there: your own server only sees Cloudflare’s addresses.

1. In the Cloudflare dashboard, open your domain, go to Security rules and choose Create rule › Custom rules.
2. Name it “Uptimecheck”, choose Edit expression and enter (ip.src in {95.111.205.91 2a04:3541:8000:1000::/64 94.237.50.166 2a04:3541:1000:500::/64 209.94.56.204 2605:7380:8000:1000::/64}). Add more addresses inside the braces, separated by spaces.
3. Under Then take action, choose Skip and tick All remaining custom rules, All rate limiting rules and All managed rules, plus All Super Bot Fight Mode rules if your plan has it. Among the other components, tick Browser Integrity Check and Security Level.
4. Place the rule first and choose Deploy.

Bot Fight Mode, on Cloudflare’s Free plan, can’t be skipped by a custom rule. Add an IP access rule instead: Create rule › IP access rules, enter an address, pick the action Allow and choose Create, once for each address and IPv6 range above. When an IP access rule matches first, Bot Fight Mode doesn’t act. To see what blocked a check, open Security analytics, the Events tab, and look at the Service field.

WordPress security plugins

In Wordfence, open Firewall › All Firewall Options, add the addresses to Allowlisted IP addresses that bypass all rules and save. Solid Security, All-In-One Security and similar plugins have an allowlist too. If your host runs its own firewall, such as Imunify360 or ModSecurity, ask them to allowlist the addresses. With fail2ban:

# /etc/fail2ban/jail.local
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 95.111.205.91 2a04:3541:8000:1000::/64 94.237.50.166 2a04:3541:1000:500::/64 209.94.56.204 2605:7380:8000:1000::/64

nginx

If nginx limits a path to known addresses, add ours:

location = /health {
    allow 95.111.205.91;
    allow 2a04:3541:8000:1000::/64;
    allow 94.237.50.166;
    allow 2a04:3541:1000:500::/64;
    allow 209.94.56.204;
    allow 2605:7380:8000:1000::/64;
    deny  all;
    proxy_pass http://127.0.0.1:8080;
}

To keep a rate limit for everyone else, give our addresses an empty key. nginx doesn’t count requests with an empty key:

geo $limit {
    default        1;
    95.111.205.91  0;
    2a04:3541:8000:1000::/64  0;
    94.237.50.166  0;
    2a04:3541:1000:500::/64  0;
    209.94.56.204  0;
    2605:7380:8000:1000::/64  0;
}
map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}
limit_req_zone $limit_key zone=perip:10m rate=10r/s;

Behind a CDN or load balancer, nginx sees the proxy’s address unless real_ip_header is set up.

Or allow a secret header

Addresses change when we add locations; a header doesn’t. On a Website or API monitor, choose Keyword, headers and more and add a line under Request headers, such as X-Monitor-Token: a-long-random-value. Then allow requests that carry it, for example in a Cloudflare custom rule: any(http.request.headers["x-monitor-token"][*] == "a-long-random-value"). Everyone in your workspace can see the value, so use it for nothing else.

Cron jobs and the server agent

Cron job pings and the server agent connect out to app.uptimecheck.com over HTTPS (port 443). If your servers may only reach approved hosts, allow that name. Jobs and agents set up before 16 October 2026 may use platform.uptimecheck.com, our earlier address, which still works.

Still down? See why a monitor is down when your site works. More on uptime monitoring.