Fix “Plugin not responding”
Updated 30 Aug 2026
“Plugin not responding” means Relvato can reach your site, but its plugin's REST endpoints (under /wp-json/relvato/) aren't answering with the data Relvato expects. Your site is fine — the checks that need the plugin (checkout, login, payments, the admin-roster security check) just can't run until it responds. It's almost always one of three things.
1. Confirm the plugin is active
The most common cause is simply that the Relvato plugin isn't active. In your WordPress admin, open Plugins and check that Relvato is listed and Activated. If it shows an Activate link, click it.
WordPress can also deactivate a plugin on its own: since WordPress 5.2, if a plugin hits a fatal PHP error, the built-in fatal-error protection can pause or deactivate it to keep your site online. If Relvato was working and suddenly stopped, look for it in a paused/deactivated state, re-activate it — then check your error log (last section) so it doesn't happen again.
2. A security plugin, firewall or WAF is blocking Relvato
Relvato talks to your site over the WordPress REST API, at URLs that begin with /wp-json/relvato/. A security plugin (Wordfence, Solid Security, All-In-One Security, Sucuri…), a firewall, or a CDN's bot/WAF rules can block those requests — often precisely because they don't come from a web browser. When that happens, your site returns a block or challenge page instead of Relvato's data, and Relvato reports the plugin as not responding.
The fix is to allowlist Relvato's requests. Every request Relvato makes carries an X-Relvato-Verify header and only ever calls read endpoints under /wp-json/relvato/. In your security tool or WAF, allow (whitelist) the /wp-json/relvato/ path, or requests carrying the X-Relvato-Verify header.
On Cloudflare, add a WAF skip/allow rule for the URI path /wp-json/relvato/* — and if you use Bot Fight Mode or “Block AI bots”, make sure they aren't catching Relvato's monitor on that path either.
3. A cache is serving a page instead of the plugin's data
A full-page cache — Cloudflare APO, a caching plugin, or a host-level cache — can cache a /wp-json/ URL and later serve a cached HTML page instead of live JSON. Relvato already appends a cache-buster to every request, but some aggressive setups still cache by path.
Exclude the REST API from your cache: add /wp-json/ (or at least /wp-json/relvato/) to your caching plugin's or CDN's bypass/exclusion list. WordPress REST responses should never be full-page cached.
Confirm it's fixed
After you make a change, re-run any plugin-dependent check from the site's page in Relvato (or wait for the next scheduled run). A successful run clears the “Plugin not responding” banner automatically — and Relvato re-checks the connection on its own every few minutes.
If it still won't respond, open your host's PHP error log (or your security plugin's log) and look for a fatal error, or a blocked request to /wp-json/relvato/, around the time of the failure — that pinpoints which of the three causes is in play. Still stuck? Contact us and we'll help.
Plugin-not-responding FAQ
My site is up — why does Relvato say the plugin isn't responding?
They're different checks. Relvato can load your homepage (the site is reachable) but still not get a valid response from the plugin's /wp-json/relvato/ endpoints — usually because the plugin is inactive, or a security layer or cache is intercepting those specific requests.
Which requests does Relvato make, so I can allowlist them?
Read requests to your WordPress REST API under /wp-json/relvato/, each carrying an X-Relvato-Verify header. Allowlisting that path (or that header) in your security plugin or WAF is enough — these checks don't change anything on your site except the explicit one-click fixes you choose to run.
Will re-activating the plugin lose my settings?
No. Relvato's connection and settings are keyed to your site and survive a deactivate/re-activate. Just re-activate it under Plugins.
It cleared on its own — did I need to do anything?
If the cause was transient (a brief WAF challenge, or a cache entry that expired), the next successful check clears the banner automatically. If it keeps coming back, work through the three causes above — it's a persistent block, not a blip.