Suggestion: Change WordPress app health check endpoint to /wp-json/ or alternatives

[d19dotca]

Hi team,

I’ve been digging into how the WordPress (Developer) app reports container health, and I noticed the check currently requests /wp-includes/version.php.

This seems to work functionally, but I’m running into an edge case where WP Umbrella’s Site Protect feature (which is really just Patchstack under the hood) flags these requests from the Docker bridge IP (172.18.0.1). Patchstack is treating direct access to php files as a security threat and it becomes blocked. This generated a 403 response in the application logs for the health check:

Dec 01 21:49:20 - - - [02/Dec/2025:05:49:20 +0000] "GET /wp-includes/version.php HTTP/1.1" 403 20171 "-" "Mozilla (CloudronHealth)"

(Side note: I am surprised that this doesn't trigger any issues in Cloudron. Shouldn't it expect a 200 response? Or is the logic perhaps anything that isn't a 5xx is treated as "healthy"? )

This got me thinking... is this current health check considered best practice? According to our AI overlords, lol, this is not the best health check endpoint and can trigger security concerns much like it does currently with Patchstack blocking direct access to the WordPress core php files.

---

A small change that could help

Would it be possible to switch the health check endpoint to /wp-json/ instead of /wp-includes/version.php?

Reasons this might be a better option:

• It exercises the WordPress stack more realistically (PHP + WP bootstrap + DB).
• It’s intentionally public and very lightweight.
• It avoids triggering Patchstack rules (and other security plugins perhaps) that look for and block direct access to internal core PHP files.
• No plugin or file changes needed inside the app.

It still keeps things simple while being a bit more aligned with how WordPress expects to be probed.

---

Another possible idea for health checking

If you ever want an explicit health endpoint, a tiny MU plugin exposing something like /wp-json/cloudron/v1/health and returning { "status": "OK" } could provide a dedicated probe that works cleanly in all environments. But /wp-json/ is more than adequate for now, I think.

---

Fallback idea

If the goal is only to confirm the web server is responding, even a HEAD / check would avoid the security flags.

---

Happy to test anything on my end.

Thanks as always for all the work you do! Cloudron has been very solid in my environment and the latest improvements for 9.0 have been great to see.

[girish]

@d19dotca said in Suggestion: Change WordPress app health check endpoint to /wp-json/ or alternatives:

(Side note: I am surprised that this doesn't trigger any issues in Cloudron. Shouldn't it expect a 200 response? Or is the logic perhaps anything that isn't a 5xx is treated as "healthy"? )

yes, anything other than 5xx is considered "healthy".

In the end, the purpose of Cloudron's own health monitor is only to detect basic errors in containers. A 4xx could indicate some auth error, but also indicates something is running.

If you want true up/down monitoring, this has to be done from outside the Cloudron server network and has to be polled from various locations/networks in the world.

If the 403 logs annoy you, maybe it can be suppressed using some apache config ?

[d19dotca]

@girish Thanks for the quick reply, that makes sense to me.

I’m not worried about Cloudron’s health logic itself; the main thing I’m running into is that the current path (/wp-includes/version.php) consistently triggers Patchstack because it resembles direct access to a core WordPress PHP file. That leads to a lot of blocked requests and noisy logs, even though the container is functioning normally.

Switching the health check to something like /wp-json/ would still meet Cloudron’s requirement (“anything non-5xx is healthy”), but it would avoid these false positives entirely. As a bonus, it also reflects more accurately that WordPress is actually up and running dynamic code.

I do already monitor sites externally, so no concerns there... this suggestion is more about the internal health check interacting unexpectedly with modern WordPress hardening tools. As these tools become more common, using an endpoint like /wp-json/ might help avoid similar issues for other users without changing Cloudron’s expectations for the liveness of an application like WordPress.