A downtime alert you think is wrong

You get an alert saying a site is down, you open the site in your browser, and it loads perfectly. That is a real situation with real explanations, and almost all of them are one of two things: something in front of the site refused us in particular, or the site answered in a way a browser forgives and a monitor does not. This page is how to tell which.

Start with the cause, not with the site

Every incident records why the check failed. Open the site's Uptime tab and read the cause on the incident line:

• The site returned an error status — it answered, with 4xx or 5xx. A 403 or 429 here is the classic “blocked us specifically” signature.
• The site timed out — it did not answer in time.
• Connection refused or Network error — nothing accepted the connection.
• DNS did not resolve — the name could not be turned into an address.
• TLS certificate error — the certificate could not be verified.
• Keyword check failed — the page answered fine, but your own keyword rule was not satisfied.
• A WordPress critical error or an empty page — the site answered 200 and the body was not a working site.

The cause narrows the list below to one or two candidates. A 403 and a timeout are entirely different problems and only one of them is about speed.

It was never a single failed request

Before assuming the alert was hasty: a check has to fail twice in a row, and then an immediate confirmation check is made. Only if that third request also fails is an incident opened and an alert sent. A momentary blip does not reach you.

So “the site was up the whole time” and “three requests in a row failed” are both true more often than it sounds — which is exactly what the list below explains.

The most common answer: something is blocking our address

All traffic comes from us to your site — the plugin never calls out to WP Safer — and every request we make leaves from a single IPv4 address:

65.21.186.173

Uptime checks additionally identify themselves with the user agent WPSafer Monitor. A site that opens in your browser can still be closed to that address: firewalls block by IP, and a challenge page or a 403 served only to us looks exactly like downtime from where we stand.

If the incident cause is an error status, a timeout on an otherwise fast site, or a sudden run of failures that started when you installed or reconfigured something security-related, allow our address wherever the site is filtered:

• Cloudflare — Security → Security rules → Create rule → IP access rules: the address above, action Allow, scoped to this website. One caution: an IP allow rule does not turn off Bot Fight Mode or Browser Integrity Check. Those are separate switches, and they can block us on their own.
• Wordfence — Firewall → Blocking → Allowlisted Services, under allowlisted IP addresses.
• Jetpack — Protect → Firewall: add the address to the trusted IP list and make sure the list is switched on.
• Sucuri — in the Sucuri Firewall dashboard, Security → Access Control → Whitelist IP Address.
• A hosting firewall (Imunify360, ModSecurity, a provider's own WAF) — this one is not in WordPress and you usually cannot reach it. Send your host one line: please allow the IP address 65.21.186.173 for my domain.

With some security plugins there is a shortcut: on a site whose WP Safer plugin is recent enough, the WP Safer screen inside that site's own wp-admin offers an Allow WP Safer button which writes the allowance for you. Nothing is written until you press it, and you can withdraw it later from the same place.

The same block stops backups, updates and scans on that site, not only the uptime check — so this is worth fixing even if you were ready to live with the false alert.

The site answered, but too slowly

We wait 10 seconds for a connection and 15 seconds in total. A page that takes 20 seconds to build does load in a browser, where you are willing to wait and watch a spinner; here it is recorded as a timeout.

If that is your cause, the response-time chart on the Uptime tab and — on Pro and Agency — the DNS / TCP / TLS / server breakdown tell you which part of the request is eating the time. A site that normally answers in 400 ms and times out at 3 a.m. is usually a scheduled job, a backup or a neighbour on the same server, not a WP Safer problem.

The certificate is fine in your browser and not for us

We verify TLS properly and we do not make exceptions. Two configurations pass in a browser and fail here: a certificate chain missing its intermediate — desktop browsers often fill that in from cache, we do not — and a certificate that has only just been renewed, on a server that has not been reloaded, so the old one is still being served.

Check the site with an external SSL test before concluding the alert was wrong. A missing intermediate also breaks real visitors on some phones.

Redirects

We follow up to five redirects. A redirect loop, or a chain longer than five hops, ends as a failed check. Browsers allow more, which is why a chain like http → https → www → trailing slash → language prefix can be invisible to you and terminal for us.

The keyword rule was too strict

If you set a keyword on Pro or Agency, remember what it is compared against: the HTML the server returned. We do not run JavaScript. A word that appears on screen because a script wrote it there is not in that HTML, and the rule fails on every check while the page looks perfect to you.

Pick something that is really in the source — part of the footer, a heading, the site name — and check the spelling and the language of the page you are watching. A word rendered by a cookie banner, a personalised block or a page that varies by country is a poor rule for the same reason.

HTTP 200 that we call downtime anyway

On paid plans we read the body, because a WordPress fatal error answers 200 and a ping-only monitor would call that site healthy. A 200 is recorded as downtime when the body contains a WordPress error page, a database connection error or a PHP fatal error leaking onto the page, or when it is practically empty — under about half a kilobyte with no text in it.

The one honest false positive here is a site whose home page genuinely is almost empty HTML, because everything is drawn afterwards by JavaScript. If that is your architecture, that is what you are seeing.

A page that mentions the critical-error sentence — an article explaining how to fix it, say — is not flagged: the text markers only apply to bodies under 8 KB, on the assumption that a real error screen is small and an article about one is not.

Things that look like alerts but are not downtime

Under Monitoring notices on the Uptime tab, marked “not downtime”, you will find WP-Cron falling behind, the WP Safer plugin going quiet, DNS records changing, nameservers changing, and a domain name approaching its expiry date. These never appear in your uptime percentage and never open an incident. If the message you received was one of these, the site was not reported as down.

What you cannot do, and what happens next

There is no “check again now” button, and that is deliberate — a monitor you can ask for a second opinion is a monitor whose history you can shape. The next scheduled check closes the incident by itself on the first success, and the recorded downtime runs from the first failed check to that recovery, not from the moment you were alerted.

Checks are made from a single location, our node in Finland. We say so on the fleet page and in the footer of the public status page, and it is the honest limit of everything above: when we cannot reach a site, that means we could not see it — not that nobody could.

If the cause does not match anything here, write to info@wpsafer.com with the site name, the time of the incident and the cause shown on the incident line. Those three things are enough for us to find the exact request in our own records.