Site Health can report a REST API error or a failed loopback request while the public site still works. The REST test checks whether WordPress can request its own REST endpoint. The separate loopback test checks a request back to the site. cURL error 28 means a request exceeded its timeout; other REST or loopback errors can have different causes. The block editor uses the REST API to load and save content. Visit-triggered scheduled tasks rely on WordPress being able to start cron, unless your host runs a separate scheduled job.
Work this checklist in order. Prefer staging when you can reproduce the Site Health critical issue there. Take a backup before pausing security plugins, changing firewall rules, or asking the host to change connectivity or DNS behavior on production. This article is about Site Health REST API, loopback, and cURL error 28 warnings. If the site is offline for visitors, use site down first. If the editor shows “Publishing failed” or an invalid server response while Site Health is clean, use publishing failed. If posts stay “Missed schedule,” also see missed schedule. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what failed
- Open Tools → Site Health → Status, expand the warning, and copy the complete error wording (REST API, loopback, cURL error 28, unexpected status, or other transport message).
- Record the reported endpoint if shown, and the timeout duration if shown. Use Site Health → Info only for supporting server details.
- Note whether the public homepage still loads while Site Health fails. A working homepage does not prove that the reported REST endpoint or loopback request works.
- If visitors see downtime or host errors, stop and use site down first.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Site Health: REST API error; site still loads | REST endpoint request | Copy the warning’s reported endpoint and error; retest after pausing security plugin on staging |
| Site Health: loopback failed; site still loads | Loopback request | Copy the loopback warning text; retest after pausing security plugin on staging |
| cURL error 28 / operation timed out | The reported request exceeded its timeout | Host connectivity or firewall on that URL; slow PHP/origin; DNS/proxy route from the server |
| Started after a firewall or security plugin | Plugin / WAF blocking the reported request | Pause that plugin on staging; allow the exact blocked rule for the reported URL |
| Server cannot reach the reported site endpoint | Host connectivity / firewall | Ask host to test the reported URL from the WordPress server |
| Hostname reaches the wrong site or cannot be reached from the server | DNS or proxy route | Confirm intended DNS/proxy from the WordPress server; do not force an origin-IP match |
| Editor save / schedule fails; Site Health REST or loopback critical | REST or cron behavior needs checking | Retest editor saves and scheduled tasks separately |
| Publishing failed / invalid JSON; Site Health clean | Editor response path | Publishing failed checklist |
Safe diagnostic order
- Capture the failed test and endpoint. In Tools → Site Health → Status, expand the warning and copy its complete error, reported endpoint if shown, and timeout duration if shown. Use Info for supporting server details. Send your host the actual failing URL and test name.
- Confirm the public site still responds. Load the homepage and wp-admin in a private window. If the site is down for visitors, fix availability with site down before chasing REST or loopback warnings. A working homepage does not prove that the reported REST endpoint or loopback request works.
- Pause security / firewall plugins on staging. On a staging copy (or a short, supervised production window if staging is impossible), temporarily disable the security, WAF, “disable REST API,” or firewall plugin that changed last. Re-run the affected Site Health tests. If the warning clears, identify the rule that blocked the reported request and plan an allowlist or exception. Do not leave a security plugin disabled as the permanent fix.
- Ask the host to test the reported request from the server. Have the host check DNS resolution, outbound connectivity, redirects, and any firewall or bot challenge on that exact URL. A request to the site’s public hostname is not necessarily a request to localhost or 127.0.0.1. Change only the rule shown to block the request. If the warning shows a timeout near the Site Health test budget (commonly about 10 seconds for these tests), ask the host whether that exact URL responds within that window from the app server.
- Confirm the intended DNS and proxy route. Ask your host or DNS provider whether the hostname resolves as expected from the WordPress server and reaches the correct site. A CDN-proxied hostname can correctly resolve to CDN addresses rather than the origin IP. Do not replace valid proxy records merely because they differ from the hosting IP.
- Rule out a chronically slow origin. If the host confirms the reported URL is reachable but responses exceed the Site Health test timeout, ask them for PHP/origin TTFB under load and for any rate limits on repeated server-side requests. Fixing a slow origin is the durable fix; raising timeouts without fixing slowness only hides Site Health warnings.
- Retest with protection restored. Restore any security plugins paused for testing and keep the approved rule correction. Re-run the affected Site Health tests. Save a draft in the block editor and test a scheduled post on staging if scheduling was affected. Confirm each relevant action works with protection enabled. If schedules still miss after REST/loopback clears, see missed schedule.
Common causes
- Security, firewall, or “disable REST API” plugins blocking the reported REST or loopback request.
- Server cannot reach the reported site endpoint (firewall, bot challenge, or outbound block on that URL).
- Hostname reaches the wrong site or cannot be reached from the WordPress server (including broken DNS; valid CDN proxy records are not automatically wrong).
- Origin or PHP so slow that the reported request exceeds the Site Health test timeout (cURL error 28 when that test times out).
- Confusing a Site Health REST or loopback warning with a full public outage, or with a separate editor “publishing failed” JSON error when Site Health is clean.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site where Site Health shows a REST API error, loopback failure, or cURL error 28: capturing the failed test and endpoint, testing a security-plugin pause safely, framing the host connectivity/DNS ask for the reported URL, and retesting the affected REST or loopback check and the relevant editor or scheduling action. Paste the Site Health error wording, the reported endpoint if shown, the Site Address URL, whether the public homepage still loads, and when it started. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full security rebuilds, host migrations, performance projects for a chronically slow server, and public outages are outside this offer. Use site down for visitor-facing downtime and publishing failed when the editor fails without a Site Health REST/loopback critical.
Related checks
If Site Health still reports REST API, loopback, or cURL error 28 after a security-plugin staging test with protection restored, a host check of the reported URL from the server, confirmed intended DNS/proxy routing, and a sane origin response time, send your host the Site Health error text, reported endpoint, Site Address, and the start time. Suspected compromise needs a security investigation in addition to restoring the failed check.