Health endpoints#

The health server runs on a dedicated port (default 8081) in a background daemon thread, separate from the Zope WSGI server. It answers even when all Zope worker threads are busy.

The health server is started by the egg:plone.observability#healthserver WSGI filter. It is not started on Zope process startup, so zconsole and script runs never touch the health port. See How to install plone.observability for wiring the filter.

Endpoints#

/live: Liveness check. Answers whether the process is alive. Must not depend on the database or any external service.
/ready: Readiness check. Answers whether the process can currently serve requests. Evaluates the registered readiness checks, including ZODB connectivity.
/startup: Startup check. Answers whether the process has finished initializing. Evaluates the readiness checks itself and latches on the first success: once it turns green, it stays green.

The /startup latch is deliberate. Kubernetes does not run the readiness probe until the startup probe has succeeded, so /startup cannot depend on /ready having been polled first. It must stand on its own.

/ready and /startup share one readiness run at a time. A probe that arrives while a run is in progress does not start another one and does not wait for it. It gets the last result, or 503 if there is no result yet or the run is older than PLONE_OBSERVABILITY_READINESS_STUCK_AFTER. Results are reused for PLONE_OBSERVABILITY_READINESS_CACHE_TTL seconds. See Configuration.

Response format#

All endpoints return JSON. The HTTP status is 200 on success and 503 on failure.

{
  "status": "ok",
  "checks": {
    "zodb": {"ok": true, "message": "ZODB connection ok"}
  }
}

Each entry in checks is keyed by the check name and reports a boolean ok and a human-readable message.

While a readiness run is in progress and no usable result is available, checks is empty and a top-level message says why:

{
  "status": "failed",
  "checks": {},
  "message": "readiness check in progress for 42s"
}