The pattern. Jetpack and ManageWP false-report downtime for two reasons: a roughly ten-second timeout that trips on a slow shared-hosting load (or a firewall and security plugin that blocks the probe), and a homepage HTTP 200 check that stays green while a broken checkout or locked-out wp-admin sits behind it. The durable fix is depth, not a different external vendor: allowlist the probe to stop the false alarms, then monitor what a real user does. Velprove's browser login monitor signs into your own wp-login.php and asserts a logged-in-only string, so it fails the moment wp-admin breaks instead of reporting a green homepage.
To put numbers on it: Jetpack checks from WordPress.com servers in the United States every five minutes via an HTTP HEAD request, and ManageWP checks from its own external network on a similar interval. Both are external checks, and both fail in the same two opposite directions. They cry wolf, sending a phantom "your site is down" email while real visitors load the page fine. And they go blind, staying green while a real outage runs on a part of the site the homepage check never looks at. You can build all of this on the free plan, no credit card required.
The two ways a built-in WordPress uptime monitor sends false reports
Jetpack's Downtime Monitor and ManageWP's uptime monitor are the two most common built-in options a WordPress owner reaches for. Both are external checks. Jetpack, per its own support documentation , runs from WordPress.com servers: "one of our servers will start checking your site every five minutes," and it "pings your site's homepage every five minutes, via a HTTP HEAD request." ManageWP checks externally on a similar interval. Neither one is a process living on your server. They both reach in from the public internet, which is the right place to monitor from.
That shared design is exactly why both fail the same two ways. The first failure is a false alarm, a cry wolf. The monitor sends you a "site is down" email while your site is up and serving real visitors. The second failure is the opposite, a silent miss. The monitor stays green and says nothing while a real outage is happening on a part of the site the monitor never looks at.
These two failures pull in opposite directions, and that is what makes a built-in homepage monitor so frustrating to trust. It pages you when nothing is wrong, and it stays quiet when something is. Over a few weeks of phantom emails, the natural human response is to stop reading the alerts, which is the worst possible outcome: now you have a monitor that both lies to you and gets ignored. The rest of this post takes the two failure modes one at a time, with the real complaints and vendor quotes that document them, and then lands on the fix that addresses both.
Cry wolf, part one: the ten-second timeout on slow hosting
The most common false-down alert is a timeout. Jetpack decides your site is down if it does not answer within about ten seconds on a check. On shared hosting, a single request can blow past that window when a neighbor on the box is spiking, when an uncached page has to be rebuilt, or when a backup job is running, even though real visitors with warm caches never notice.
This is not a guess. A WordPress.org support thread from September 2024 captures the experience precisely. User @philipgilson posted on the WordPress.org forums (last modified 2024-09-22):
- "I am repeatedly getting emails from JetPack that my website appears to be down... Then another saying it's back online. This happens a lot. however when I try to load the website it's not slow to load and loads fine. Error reference: 234058489/intermittent." *
A site that is genuinely down does not come back online thirty seconds later, over and over, while loading fine the whole time in a browser. That up-down-up flapping with an /intermittent error reference is the signature of a timeout, not an outage. And Jetpack's own staff confirm the mechanism. In the same complaint family, an Automattic staffer explained it directly:
- "If your site is slow to load, it could trigger a notice that it is down... the site may actually be loading, but it's just slow, and Jetpack thinks that this slowtime is instead a sign that the site is offline." *
The same thread documents the exact threshold and the fact that you cannot change it: "the Jetpack requests timed out, meaning that your site does not respond to these requests after 10 seconds," and "there's no way to adjust the time that the Monitor checks your site, it's either on or off." So the timeout is fixed, the threshold is short, and on slow hosting it trips on a load that a human would happily wait out. This is a real, persistent, vendor-acknowledged behavior, not a recent regression, and it is the number-one source of phantom "down" emails.
The important diagnostic move here is to separate a false alarm from a site that genuinely keeps falling over. If your site really is going down on a recurring basis, the timeout alert is correct and the problem is upstream of the monitor. We walk through the real causes of a recurring outage, from memory limits to plugin conflicts to host throttling, in why your WordPress site keeps going down . If, instead, the site loads fine every time you check and the alerts flap up and down, you are looking at a cry-wolf timeout, and the fix is not to keep restarting things. It is to monitor differently.
Cry wolf, part two: your firewall or security plugin blocks the probe IPs
The second false-down cause is a block. The probe never reaches WordPress because something on your side stops it at the door: a host firewall rule, a security plugin like Wordfence, a geoIP block, or a rate limiter that decides a request hitting your homepage every five minutes from the same place looks like a bot. The page loads fine for you because your request is not the one being blocked. The probe is.
For Jetpack specifically, there is an extra dependency that makes this worse: the connection layer runs through xmlrpc.php. A WordPress.org thread from early 2022 shows the volume this can reach. User @johnnyivan reported on the WordPress.org forums (thread last modified 2022-03):
- "For a couple of weeks, JetPack's sending me hundreds of emails saying my site's down, then back up again. Error reference: 142945637/intermittent... I contacted my hosting provider and they can see nothing wrong, and neither can I." *
An Automattic staffer in that thread named the cause:
- "When we try to test your site's xmlrpc.php file (which Jetpack uses to communicate with your site), it is timing out... some hosts block connection requests to that file." *
Here is the tension. Many WordPress owners deliberately block or disable xmlrpc.php, because it is a well-known target for brute-force login attempts and pingback amplification attacks. That is a defensible, even recommended, security posture. But the moment you do it, Jetpack Monitor loses its connection path and starts emailing you phantom downtime. You did the right thing for security and got punished with a noisy monitor. Blocking harder does not fix it, and unblocking xmlrpc.php weakens your security to satisfy a monitor, which is backwards.
ManageWP hits the same wall from a different angle. It checks from an external network, and that external probe gets firewalled like any other outside request. A common symptom is a timeout error of the form "Response timeout, did not receive response for 30sec" thrown against a site that is loading perfectly in a browser. A security forum discussion of this exact error describes the cause plainly: a response timeout like that "usually indicates that some security configuration is blocking requests." (We are not naming ManageWP's backend probe vendor here, because the only sourcing for that is a single third-party forum, not a ManageWP document. The point stands without it: ManageWP checks externally, and the external check gets blocked the same way Jetpack's does.)
The honest fix for both is allowlisting, not blocking, and it is worth stating clearly because the forum advice often gets this backwards. You allowlist the specific monitor so your security layer stops eating its requests, and you keep the rest of your hardening in place. But allowlisting alone only stops the false alarms. It does nothing about the second, quieter failure, which is the subject of the next section.
Going blind: a homepage 200 is not proof your site works
Now flip the failure mode. Jetpack pings your homepage with an HTTP HEAD request and reads the response. ManageWP assesses your site's status from its response code, with an optional single-keyword match on the homepage. In both cases the monitor is asking one question: did the homepage answer with a 200? And an HTTP 200 is not proof that your site works. It is proof that one URL returned a success code.
Think about what actually breaks on a WordPress site and where it lives. A WooCommerce checkout that throws a fatal error on the payment step. A wp-admin that locks every editor out after a plugin update. A membership area that silently logs users out because a session table filled up. A page that renders a white screen below the fold while the header and footer come through fine. Every one of those can sit behind a homepage that still returns 200. The monitor sees green. Your customers see a dead checkout. This is the general shape of a silent outage, and we cover the broader pattern, including why most uptime tools miss it, in why uptime monitors miss real outages . The Jetpack and ManageWP version is just the most common WordPress instance of it.
This is not a complaint we are quoting from a forum, because owners rarely file a support ticket that says "my monitor stayed green during an outage" (they never knew the monitor should have caught it). It is an architectural limit you can reason about directly. A monitor that only knows the homepage status code can only ever tell you the homepage answered. It is structurally incapable of telling you that the logged-in dashboard renders, that the checkout completes, or that the members area still authenticates, because it never asks. The optional ManageWP keyword match helps a little, but only on the homepage, and only against a single static string, so a white-screen checkout three clicks deep is still invisible.
The takeaway is uncomfortable but clean. The cry-wolf problem makes the monitor annoying. The go-blind problem makes it dangerous, because it gives you a false sense of safety. A green pill on a homepage HEAD check is the monitoring equivalent of checking that the front door opens and concluding the whole house is fine.
Why "switch to another external monitor" does not fix it
The usual advice when Jetpack gets noisy is to switch to a dedicated external uptime monitor. Plenty of articles frame this as "external monitoring is the key," and Automattic staff have themselves recommended moving to a separate service in support threads. Switching off the built-in monitor and onto a dedicated one is reasonable. But if the dedicated monitor you switch to is just another homepage status check, you have not fixed anything. You have moved the same two failure modes to a different logo.
Walk it through. Both Jetpack and ManageWP already check your site from the outside, so swapping one outside vendor for another that does the same shallow thing changes nothing. A second homepage-200 monitor inherits both problems: it still times out on a slow shared-hosting load, it still gets firewalled if your security layer blocks its probe, and it still goes blind to anything behind a 200. You have changed vendors, not failure modes.
What actually moves the needle is depth plus robustness. Depth means checking what a user actually does, the login flow, the post-login content, a money path, rather than only whether one URL returns a status code. Robustness means a probe that is harder to false-trip and a configuration that does not page you on a single slow load. If you want to move off a plugin entirely and run your monitoring from outside WordPress, the mechanics of doing that cleanly, without touching wp-content, are in monitoring WordPress uptime without a plugin . The point of this section is narrower: do not let the "just go external" advice convince you that the vendor was the problem. The shallow check was.
The durable fix, in plain steps: monitor what a user does
The fix is to stop asking "did the homepage return 200" and start asking "can a real user do the thing they came here to do." That is four moves, and the first one is the differentiator. None of this involves any configuration file or API payload. You build each of these in a wizard, step by step, the same way you would set up a forwarding rule in your email client.
Move one: a browser login monitor on your own wp-login.php. This is the move that catches the most, and it is the one a homepage HEAD request can never replicate. Velprove's browser login monitor opens your own wp-login.php in a real browser, signs in with a dedicated Subscriber-role test account, waits for the dashboard to load, and asserts that a logged-in-only string is actually on the page. If wp-admin locks everyone out after a plugin update, this monitor fails on the next check, because the real browser cannot reach the signed-in state. A status-code probe would have stayed green the whole time. Step one in the wizard: a real browser opens yourdomain.com/wp-login.php. Step two: it signs in with the test account's username and password. Step three: it asserts that a logged-in-only string (the "Howdy" greeting, the admin bar, a dashboard widget label) is present. If you want the step-by-step setup of a wp-admin login monitor specifically, with screenshots, that lives in how to monitor your wp-admin login .
One hard rule on this move, because it is the most common mistake. Point the browser login monitor at your own wp-login.php on your own domain, where you control a dedicated low-privilege test user. Do not point it at WordPress.com or Jetpack's own login, which sit behind device verification and email codes a monitor cannot complete (this is covered in the FAQ below). And never wire your real admin credentials into a monitor. Create a throwaway Subscriber account whose only job is to prove the login flow works.
Move two: a content assertion on the homepage, not just a status code. Keep an HTTP monitor on the homepage, but make it assert on a specific string that only renders when the page actually built correctly. The title of your latest post, a footer copyright line with the current year, a product name. A white screen of death often still returns a 200 with an almost-empty body, so a status-only check passes while the page is blank. A body assertion on a real string fails the moment the content stops rendering. The wizard move: add the homepage URL, then add a body-contains assertion on a string you know is always on the page.
Move three: a multi-step monitor for a money path. If your site sells something or has a multi-page flow that matters, a multi-step monitor walks a short sequence of requests in order and asserts at each stop. Velprove's free plan covers a multi-step monitor of up to three steps, which is enough to fetch a page, follow it to the next, and assert that the expected content arrives. Each step asserts against a static expected value, a status code or a known string, not a moving target. Velprove runs each step once in sequence; there is no polling or wait-for-condition primitive, so if you need a freshness check, your own endpoint should compute that server-side and the monitor asserts a 200 on it. The wizard move: add step one, add its assertion, add step two, and so on, up to three.
Move four: spread your HTTP and multi-step monitors across regions. A single blocked region is one of the cry-wolf causes from earlier. All five Velprove regions (North America, Europe, United Kingdom, Asia, Oceania) are available on every plan, including free. HTTP and multi-step monitors can be distributed across regions, so running the same homepage assertion from a few different locations tells you whether a failed check is your site falling over or just one regional path getting firewalled or hitting a CDN issue. The browser login monitor runs from one region at a time, so pick the region closest to most of your users for that one. If a probe from a single location trips while the others stay green, you are looking at a one-path problem, not a site-wide outage.
Those four moves fit inside Velprove's free plan: 10 monitors total, one browser login monitor, a multi-step monitor up to three steps, all five regions, email alerts, no credit card required, and commercial use allowed. The browser login monitor on your own wp-login is the piece that separates this from yet another homepage ping, and it is the piece neither Jetpack nor ManageWP can do.
What to do with Jetpack or ManageWP once you have real monitoring
Once a deeper monitor is watching the login flow and real content, the built-in monitor has one of two honest jobs left. You can keep it on as a free homepage backstop, a second pair of eyes on the single thing it can actually see, and treat its alerts as low-priority hints rather than pages. Or you can turn it off to stop the noise, especially if the cry-wolf timeouts and the xmlrpc.php blocks have already trained you to ignore its emails. Both are reasonable. A monitor you ignore is worse than no monitor, so if Jetpack's false alarms have burned your trust, turning it off and leaning on the deeper monitor is the cleaner choice.
The bigger structural question, whether a WordPress owner should run a built-in plugin monitor at all, which segment each tool fits, and how to choose among the options, is not what this post is for. This post is about why the false reports happen and how to make them stop. The full landscape decision lives in our complete guide to WordPress uptime monitoring , which walks the whole field including where Jetpack Monitor and ManageWP fit and when each one is enough. If you arrived here trying to decide what to use rather than why the alerts are lying to you, start there.
Frequently Asked Questions
Why does Jetpack Monitor keep emailing that my site is down when it loads fine for me?
Two causes account for most of these phantom alerts. First, Jetpack flags your site down if it does not answer within about ten seconds, and a busy shared host can blow past that window on a single check while real visitors with warm caches load the page fine. The alert body usually says your site is responding intermittently or extremely slowly and carries an error reference ending in /intermittent. Second, something on your side blocks the probe before it ever reaches WordPress: a firewall rule, a security plugin, a geoIP block on the United States where the Jetpack servers live, or a blocked xmlrpc.php file that Jetpack relies on to talk to your site. The page loads for you because your request is not blocked. The probe is. Allowlisting the probe and adding a deeper check that asserts on real content is the durable fix, not turning the timeout knob, because Jetpack does not expose one.
Why does ManageWP show my site as down when it is up?
ManageWP checks your site from an external network, the same way any outside monitor does, and that external probe gets firewalled like any other. A common report is a "Response timeout" that did not receive a response within thirty seconds on a site that is loading fine in a browser, which usually traces back to a security configuration on the host or a security plugin blocking the request before WordPress answers. The first move is to confirm the site really is up from several places, then allowlist the probe so the security layer stops eating it. The deeper move is to monitor what a signed-in user actually does, because a status-code probe will keep reporting a green homepage even when the part of the site your customers use is broken.
Can a five-minute homepage monitor miss a real outage?
Yes, in two ways. A short outage that opens and closes inside the five-minute gap between checks can be invisible simply because no check landed during it. More importantly, both Jetpack and ManageWP look at whether the homepage returns an HTTP 200, and an HTTP 200 is not proof the site works. A broken checkout, a locked-out wp-admin, a logged-out members area, or a white screen below the fold can all sit behind a 200 response. The homepage answers, the status code is green, and the part of the site that makes you money is dead. A monitor that asserts on real content or drives a real login catches that class of failure. A status-code probe cannot.
Should I block the monitor's IPs or the xmlrpc.php requests to stop the noise?
Blocking is what causes the false alerts in the first place, so blocking harder is the wrong direction. Jetpack Monitor depends on a reachable xmlrpc.php to talk to your site, and many WordPress owners disable or block xmlrpc.php for security because it is a common brute-force and amplification target. That is a reasonable security posture, but it breaks Jetpack's connection and produces phantom downtime alerts. The fix is to allowlist the specific monitor's requests rather than turn off your security, or to move the uptime signal to a monitor that does not depend on xmlrpc.php at all. Pair the allowlist with a monitor that checks depth, a real content assertion or a real login, so you are protected and not paged on noise.
Will a browser login monitor work against WordPress.com or Jetpack's own login?
No. Point a browser login monitor at your own wp-login.php on your own domain, where you control a dedicated low-privilege test account. It will not work against WordPress.com, the Jetpack dashboard, or any consumer login you do not control, because those sit behind device verification, email codes, and captchas that a monitor cannot complete. That limitation is fine for the WordPress owner, because the surface you actually want to verify is your own login at yourdomain.com/wp-login.php with a Subscriber-role test user, which is exactly where a browser login monitor belongs.
