Hosting compatibility

Firewalls that answer for the site

Imunify360, Sucuri, Cloudflare and Wordfence all sit between the platform and the site and decide, per request, whether the caller looks like a bot. The platform's calls are not a browser — no cookies, no JavaScript, a fixed client — and any of these may refuse them, sometimes only after a period of normal traffic, sometimes only for one call in ten.

The refusal takes different shapes — a challenge page, a block page, a plain refusal — and the platform recognises each of them and reports the site as blocked by a firewall with the provider named, rather than as "inactive". A page that says "one moment, please" is not the site, and the platform does not read it as one.

What still works on a blocked site

Since worker 2.3.0 a site the platform cannot call still:

• reports its state — worker version, environment, plugins, themes, users, core, health, backups — on its own schedule;
• takes its work — a backup, an upload to storage, a sync — from the platform's answer to that report and runs it on its own WP-Cron;
• records what happened and sends it on the next contact.

What does not work on a blocked site is anything the platform has to drive step by step from its side: an update round, a restore, a worker update pushed by the platform. The site's Health page shows both directions separately, so a site that is blocked from the platform's side and fresh from its own reads as exactly that.

What a person has to do

The platform never tries to get past a firewall. When it finds one it writes an instruction on the site's Health page: the provider it recognised, the platform's address, and where on that provider that address is allowed. Allowing it restores the connection; the platform notices on its next check, marks the site recovered, and — if the site's worker is behind the current release — starts a rollout for that one site.

Authentication plugins

A JWT authentication plugin owns the Authorization header on the WordPress REST API and answers a bearer token it does not recognise before the worker runs, with an error of its own such as Wrong number of segments. The platform reports this as authentication failed and names the plugin's involvement.

Two ways out: exclude the wpocto/v1 namespace in the plugin's settings, where it offers that; or run worker 2.3.0 or later, which reads the platform's own header and leaves Authorization to the plugin. The second needs the site to have reached 2.3.0 — by rollout where the platform can reach it, or by uploading the zip once where it cannot. The namespace is the one the site's Health page names when the platform finds such a plugin in the way; it is written here so a host administrator can act on it without the page in front of them.

Caches

LiteSpeed Cache caches the WordPress REST API by default and ignores the standard Cache-Control: no-store header. The worker uses the plugin's own settings to mark its answers as not cacheable, so an authenticated answer is never served to the next caller. Other page caches honour the standard headers the worker sets. A cache that still answers for the site is visible in the dashboard as data that does not change when it should; exclude wp-json/wpocto/v1 in the cache's settings. Where the platform itself finds a cache serving the worker's answers, the site's Health page names that path as the thing to exclude.

Hosts known to need attention

Rather than a list of hosting companies — which is wrong the day it is written — the platform classifies every site it cannot reach by what it found, and the classification is what to act on. Troubleshooting lists each state.