
WordPress has no honest health endpoint. The front page, admin-ajax.php and the usual
health.php stubs all return 200 while the database is down, the object cache is gone, or
WordPress is serving its “database update required” interstitial. Every probe in common
use calls that pod ready.
Klarsmith Ops Kit gives a containerised WordPress site three things operators actually need:
GET /wp-json/ops/v1/readyz returns 200 only when the databaseGET /wp-json/ops/v1/metrics serves the text expositionwp ops collect writes to the object cache on a schedule.wp_ops_snapshot_age_seconds tells you when thewp_ops_pod_*) and site-level serieswp_ops_site_*) are split so replicas do not duplicate site numbers.WP_OPS_LOG_JSON=true, PHP errors and fatals go toThe plugin fails closed. /metrics is disabled until a token is configured, and the
anonymous readiness response names failing checks without leaking detail.
Configuration is by environment variable, which is how containers are configured:
WP_OPS_TOKEN — bearer token for /metrics (Authorization: Bearer orWP_OPS_SITE_NAME — site label on JSON log records (metrics carry no siteWP_OPS_EXPECT_OBJECT_CACHE — fail readiness when no external object cache is active.WP_OPS_REQUIRED_PLUGINS — comma-separated plugin files (dir/plugin.php) thatWP_OPS_REST_BYPASS_AUTH — set to false to stop the plugin allowing anonymousWP_OPS_LOG_JSON — set to true to emit JSON log lines on stderr.WP-CLI commands: wp ops check (exit 1 on any failing check), wp ops collect
(refresh the snapshot), wp ops metrics (print the exposition locally).
Source, issue tracker and Kubernetes manifests for probes, the collector CronJob and
scraping live at https://github.com/klarsmith/wp-ops-kit.