Your site could not complete a loopback request
WordPress made an HTTP request to its own address and did not get an answer. Several features depend on that working.
Your site could not complete a loopback request. This may prevent the Site Health check from working…
Make the same request the site makes, from the server itself, and read what comes back. A refused connection, a TLS error and a 401 are three different problems, and the response tells you which one you have in a single command.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| HTTP authentication in front of the site | The request returns 401. A staging site behind a username and password is the classic case — the browser knows the credentials and WordPress does not. | Exempt the loopback path from authentication, or give WordPress the credentials for its own requests. Removing the protection is not required. |
| The server cannot resolve its own hostname | The request fails with a DNS error while the same URL works from your laptop. The public record exists; the machine's own resolver does not know it. | Add a hosts entry pointing the site's domain at the loopback address, so requests the server makes to itself stay local instead of going out and back. |
| A firewall blocks outbound requests to itself | The connection is refused or times out with no HTTP response at all, and nothing appears in the site's access log. | Allow the server to reach its own public address and port. Egress rules that permit nothing but a few destinations catch this case without anyone noticing. |
| A certificate the server does not trust | The request fails on TLS verification — self-signed or incomplete chain — while a browser accepts it because browsers carry a different trust store. | Install the full certificate chain, or point the loopback at http on the local interface so TLS is not involved in a request that never leaves the machine. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Make the request the site is making
Run this on the server, not your laptop. The distinction is the whole point of the check.
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-cron.phpAsk WordPress to try, and print the failure
The WP HTTP API applies its own timeouts and TLS settings, so its result can differ from curl's.
wp eval '$r = wp_remote_get( home_url( "/" ) ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r ), PHP_EOL;'
Keep the request on the machine
A hosts entry removes DNS and the round trip through the edge from the equation.
# /etc/hosts 127.0.0.1 example.com www.example.com
If it is HTTP auth, let the site past it
Set the credentials WordPress should use for its own requests, in wp-config.php.
define( 'WP_HTTP_BASIC_AUTH_USER', 'staging' ); define( 'WP_HTTP_BASIC_AUTH_PASS', 'the-password' );
Re-run Site Health and check cron caught up
A restored loopback usually clears a backlog of scheduled events immediately, which is the practical confirmation.
wp cron event list --fields=hook,next_run_relative
What the platform takes off the list.
Cron runs from the platform rather than through a request the site makes to itself, so a failing loopback cannot stop scheduled work here — which is what makes this failure so damaging elsewhere: it stops publishing, updates and queued email at once, with nothing in the interface to say so. Staging sites are protected without HTTP auth in the request path, so the most common cause does not arise.
Questions, answered.
Is this actually breaking anything, or just a warning?
It only fails on staging. Why?
Can I ignore it if cron runs from a system schedule?
Why does it work from my browser but not from the server?
If that was not it.
These fail in ways that look similar from the browser.