Your website opens in the browser, but UptimeWire says it is down, with status 403, 429 or a security check page as the reason. In most cases the site is fine. Something in front of it, such as Cloudflare, a security plugin or the hosting firewall, takes our checks for unwanted robots and refuses them.

That is not a fault of the protection. Our checks come from servers in data centres, have no browser behind them and arrive on a schedule, and that is exactly what bot protection is built to stop. The fix is to tell the protection that these few addresses belong to your monitor.

Signs that the protection blocks our checks

What you see in UptimeWire What it usually means
Status 403 while the site opens for you A firewall or bot protection refuses robots
A "checking your browser" or "Just a moment" page, sometimes with status 503 A challenge page. Our checks do not run scripts and cannot pass it
Status 429 A rate limit: too many requests from one address
Status 401 The page asks for a password. Our checks do not sign in
Checks fail from some locations only A rule blocks certain countries or networks

When a test in the website form or a recent check gets one of these answers, the cabinet shows a link: "Having problems? Read how to let our checks through". It opens a short version of this guide with our current addresses.

Step 1. Take our addresses

Our checks come from a short, fixed list of servers. The current list, one address per line, is always at app.uptimewire.com/ips.txt. The same list with the location of each address is at app.uptimewire.com/ips.json, for scripts.

When we add a check location, its address appears in the list the same day. If you copied the addresses by hand, look at the list again when checks from a new location start to fail.

Our checks also introduce themselves with the name UptimeWireBot/1.0 (+https://uptimewire.com). You can use it to find our requests in a log. Do not allow by this name alone: anyone can send the same name, so an allow rule on it is an open door. Allow by address.

Warning

Allow only our addresses. Do not switch bot protection or the firewall off for the whole site to make the monitor pass.

Step 2. Allow the addresses

Find the protection your site uses below. Menu names change from time to time, so yours may differ a little from the names here.

Cloudflare, Free plan

On the Free plan, Bot Fight Mode is the usual reason for the block. Cloudflare's documentation says it cannot be skipped with a custom rule. It does not trigger, however, when an IP access rule matches the request first. So you have two options:

  1. Add an IP access rule for each address. In the Cloudflare dashboard, open your site, go to Security rules, then Create rule → IP access rules. In the older dashboard the same tool is under Security → WAF → Tools. Enter one of our addresses, choose the action Allow, apply it to this website, and add a note such as "UptimeWire checks". Repeat for every address in the list.
  2. Or turn Bot Fight Mode off. Go to Security → Settings, filter by Bot traffic, and turn Bot Fight Mode off. This lets other robots in too, so the first option is better.

An IP access rule with Allow also lets our checks past your custom rules, rate limiting rules and managed rules.

Cloudflare, Pro, Business and Enterprise

Paid plans use Super Bot Fight Mode, and a custom rule with the Skip action can bypass it:

  1. Go to Security rules → Create rule → Custom rules.
  2. Name the rule, for example "UptimeWire checks".
  3. Under the conditions, choose the field IP Source Address, the operator is in, and enter our addresses.
  4. Choose the action Skip. Tick All remaining custom rules, All rate limiting rules, All managed rules and All Super Bot Fight Mode rules. Among the products, tick Browser Integrity Check and Security Level.
  5. Deploy the rule and move it to the top of the list.

If the site is in Under Attack mode, every visitor gets a browser check that our checks cannot pass. Allow our addresses as described here and, if checks still fail, add IP access rules for them as well.

WordPress security plugins

Add our addresses to the plugin's allow list:

  • Wordfence: Wordfence → Firewall → All Firewall Options, then the field for allowlisted IP addresses (older versions call them whitelisted). One address per line.
  • Solid Security: the Authorized IPs setting in the global settings.
  • All-In-One Security: the allow list in the firewall settings.
  • Shield Security: IP Rules → create a new IP rule → add to the bypass list.

If your WordPress site is also behind Cloudflare, allow the addresses in both places.

Hosting firewalls

On shared hosting you usually cannot change the firewall yourself. Send the list to the hosting support and ask them to allow these addresses for your site. If you run the server, use the tool it has:

  • Imunify360 (cPanel, WHM, Plesk): open the Imunify360 firewall, add each address and choose the white list.
  • CSF: add each address with a comment, for example csf -a 203.0.113.10 UptimeWire.
  • fail2ban: add the addresses to ignoreip in jail.local, separated by spaces, then reload fail2ban.
  • ModSecurity: add a rule above the others that turns the rule engine off for our addresses, for example:
SecRule REMOTE_ADDR "@ipMatch 203.0.113.10,203.0.113.11" "id:1000100,phase:1,pass,nolog,ctl:ruleEngine=Off"

Replace the example addresses with the ones from our list.

Sucuri, AWS WAF, Akamai and Imperva

  • Sucuri: in the Sucuri firewall dashboard, open your site, then Access Control, enter an address under Allow IP Addresses and select Allow.
  • AWS WAF: create an IP set with our addresses, IPv4 as /32 and IPv6 as /128, and add a rule with the action Allow above Bot Control and your rate limits.
  • Akamai and Imperva: add the addresses to the allow list of your security policy or bot protection. If you do not manage it yourself, send the list to whoever does.

Blocked countries and data centres

Our checks come from several countries. If a rule blocks countries, continents or networks of data centres, put the allow rule for our addresses above it. Otherwise only some locations get through, and the results look random.

Other answers that are not a block

  • 429, too many requests: allow our addresses in the rate limit too, or choose a longer interval between checks.
  • 401, a password: our checks do not sign in. Monitor a public page instead, such as the home page or a small health page.
  • 503, a maintenance page: the monitor is right, the site does not serve visitors. For work you plan, note planned work for the website, so that it does not send alerts.

Step 3. Check that it works

  1. In UptimeWire, open the website, choose to edit it and press Test address. An answer from 200 to 399 means our checks get through.
  2. Watch the latest checks for a few hours. Every location should show a status from 200 to 399.
  3. Open the log of the protection. Our requests should now show as allowed. If they are still blocked, the log names the rule that blocked them: allow our addresses in that rule too.

If the site refuses you as well, from another network or a phone, the block is real and visitors see it too. Then the problem is in the rules or the file permissions on the server. More on that in Why your monitor shows 403 but the site works.

Checklist

  • Is the reason a 403, 429, 401 or a challenge page, while the site opens for you?
  • Did you take the current list from app.uptimewire.com/ips.txt?
  • Are the addresses allowed in every layer: Cloudflare, the plugin, the hosting firewall?
  • On the Cloudflare Free plan, did you use IP access rules rather than a custom rule?
  • Did you allow by address, not by the robot's name, and leave the protection on for everyone else?
  • Does the test in the website form now answer from 200 to 399?