Cloudflare sits between UptimeRobot and your server. Its security features can block or challenge our checks, which shows up as false downtime. Its cache can keep serving a page while your server is down, which hides real downtime. This guide covers both.
Why Cloudflare can trigger false alerts
Bot protection, WAF rules, and rate limiting can answer automated requests with 403 Forbidden, 429 Too Many Requests, or a “Checking your browser…” challenge page. UptimeRobot can’t solve a challenge, so the check fails and the monitor goes down, even though the site loads fine in your browser.
To confirm, open the incident on your monitor. The incident details show the status code, the checking IP, and the response. A challenge page in the response means Cloudflare (or another security layer) blocked the check.
Allow UptimeRobot in Cloudflare
Create a WAF custom rule that skips Cloudflare’s security checks for UptimeRobot.
In Cloudflare, go to Security → WAF → Custom rules and click Create rule.
Click Edit expression and match our requests. We recommend matching our IP addresses. You can also match our User-Agent:
User-Agent:
http.user_agent eq "Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)". Enter it exactly as shown. The+afterMozilla/5.0is part of the string, not a typo.IP addresses: add our IPs to a Cloudflare IP list and match it with
ip.src in $your_list_name. Our current IPs are on the Locations and IPs page.
Set the action to Skip (not Allow). Tick the components to skip: remaining custom rules, rate limiting rules, managed rules, and Super Bot Fight Mode. If Super Bot Fight Mode is left unticked, it can still challenge our checks.
Place the rule first in the rule order, so nothing evaluated before it can block our requests.
Deploy the rule, then pause and resume your monitor to trigger a fresh check.
A User-Agent is just a text string that any client can send, so allowlisting our IPs is the safer option.
Keep the IP list up to date. We add new monitoring locations from time to time. If you allowlisted our IPs in the past, refresh the list. A partial list causes on-and-off alerts: checks from allowed IPs pass and the rest fail. To keep it current automatically, use our JSON endpoint: https://api.uptimerobot.com/meta/ips. Text files are also available: IPv4 and IPv4 + IPv6.
Automatic HEAD to GET switch
HTTP monitors send a HEAD request by default. Cloudflare and some servers challenge or reject HEAD requests. If the HEAD request doesn't get a successful response, UptimeRobot automatically retries the check with GET. This happens on all plans, including Free, so you don't need to change anything. If the GET request is blocked too, the monitor goes down, so allowlisting is still the fix.
Still getting 403 after allowlisting?
Check the rule. Confirm it sits first and that Skip covers every component listed above.
Check where the 403 comes from. In Cloudflare’s security analytics, find a request from one of our IPs. If it shows your Skip rule matched and the request was not mitigated, but the origin returned 403, the block happens behind Cloudflare. Typical sources are your hosting provider’s own protection (common with managed WordPress hosting) or a security plugin such as Wordfence. Allow our IPs there too, or ask your host to.
Platforms that manage Cloudflare for you (for example, Shopify or managed hosts) don’t let you add your own rules. Ask the provider to allow our IPs. If they can’t, the site will keep returning errors to our checks, and we’ll keep reporting them as down.
Geo-blocking. We check from North America, Europe, Asia, and Oceania. A rule blocking any of these regions causes downtime reports from there.
Errors 520–524: Cloudflare can’t reach your server
These errors come from Cloudflare, not from UptimeRobot. For example, 522 means Cloudflare couldn’t complete a connection to your server. These are real failures between Cloudflare and your server, so allowlisting UptimeRobot or changing the SSL mode won’t fix them.
Common causes are a server firewall blocking or rate-limiting Cloudflare’s IPs, an overloaded server, or a DNS record pointing to the wrong server IP. Send the incident times from your monitor to your hosting provider. We check frequently from several locations, so we often catch short drops that visitors miss.
Will UptimeRobot detect downtime if Cloudflare serves a cached page?
It depends on what Cloudflare returns:
Cloudflare returns an HTTP error code (for example, 5xx): we mark the monitor as down.
Cloudflare serves a cached copy (for example, with Always Online) with a success code: the check looks successful, so the monitor stays up even though your server is down.
To catch outages hidden by the cache:
Bypass the cache with a cachebuster. Add
*cachebuster*to the query string of the monitored URL, for examplehttps://example.com/?*cachebuster*. Keep the asterisks. On every check, we replace the placeholder with the current timestamp, so each request has a unique URL and reaches your server.Use a keyword monitor. Check for text that only appears on your live page. Or alert when text from Cloudflare’s error or holding page appears.
Monitor your server directly. Add a monitor for the server’s IP address or for a hostname that isn’t proxied through Cloudflare (DNS only).
Check your “up” status codes. If your monitor treats a code such as 403 as up, Cloudflare blocks and errors with that code won’t trigger alerts.
Status page on a custom domain with Cloudflare
If your status page domain uses Cloudflare DNS:
Set the CNAME record pointing to
stats.uptimerobot.comto DNS only (grey cloud), not proxied.Don’t use Flexible SSL mode.
Make sure CNAME flattening doesn’t apply to the status page subdomain.
Full steps: Setting Up a Custom Domain for Your Status Page.