Asynchronous flush failed

WordPress is showing this notice in the backend:

LogHero asynchronous flush failed! This is most likely caused by your server configuration which might block requests made from your backend.

Your site is collecting requests. It is failing to send them, and that is a distinct problem with a short list of causes.

How the flush is supposed to work

The plugin does not send a request to Log Hero while a visitor is waiting. It writes to a local buffer, and when that buffer is full enough it asks your own site to do the sending, on a separate request:

GET https://example.com/wp-json/loghero/v1/flush
Token: <your API key>
User-Agent: WordPress Plugin loghero/wp@0.3.0

That call is fired and forgotten, with a 0.01 second timeout, so the visitor never waits for it. The route then posts the buffered records to https://in.app.log-hero.com/logs.

The notice means your server refused to make that call to itself, or could not resolve its own hostname to do it.

1. Try the call yourself

From a shell anywhere, with your API key from Settings → LogHero:

curl -i -H "Token: YOUR_API_KEY" \
  https://example.com/wp-json/loghero/v1/flush

200 — the route works from outside. The problem is your server calling itself, go to step 2.
403 with a Cloudflare error page — a WAF is blocking it, go to step 3.
401 or 403 from WordPress — the token does not match the saved API key. Re-paste the key in the settings and save.
404 — the REST API is disabled or the permalinks are broken. Many security plugins have a “disable REST API” switch; the route needs it on. Re-saving Settings → Permalinks fixes a stale rewrite.

If you can, run the same command over SSH on the web server itself. That is the call the plugin actually makes, and it is the one that is failing.

2. Let the server call itself

Most hosts are fine with this. The ones that are not usually fail in one of three ways:

DNS. The server resolves example.com to a public IP it cannot reach from inside, common behind a NAT or a load balancer. A hosts-file entry pointing the domain at 127.0.0.1 on that machine fixes it.
Outbound HTTP is blocked. Some managed hosts allow outbound connections only to an allowlist. Ask them to allow requests from the server to its own hostname.
The site is password protected. HTTP basic auth on a staging site intercepts the flush call before WordPress sees it. Exempt /wp-json/loghero/v1/flush, or use synchronous mode while staging.

3. Cloudflare and other WAFs

A WAF sees a request from your own server carrying an unusual User-Agent and treats it as a bot. Cloudflare in particular answers with:

Error 1010: The owner of this website has banned your access based on your browser’s signature.

Two ways out, in order of preference:

Allow the call. In Cloudflare, add a WAF custom rule that skips security checks when the URI path equals /wp-json/loghero/v1/flush and the request comes from your origin’s IP address. Scope it to that path — do not allowlist the User-Agent globally, anyone can send it.
Stop making the call. Tick Disable Async Mode, step 4.

4. Or switch to synchronous mode

If none of the above is under your control, take the asynchronous path out of the picture entirely. At Settings → LogHero → Advanced Setup, tick Disable Async Mode and save.

The plugin then sends the buffered batch inside the request that filled the buffer, with no second call to your site. It affects roughly one request in a thousand, which on most sites is not measurable. The notice clears as soon as the setting is saved.

This is the right answer for a site behind a strict WAF, and it is what we suggest before you spend an afternoon on firewall rules.

Check it worked

Open Settings → LogHero, reload, and confirm the notice is gone. Then open Log Hero → Bot Activity and check the Bot hits figure is rising again.

If the buffer had grown large while the flush was broken, the backlog goes out in batches of 1000 records, so give it a few minutes.