Flicker publishes a cached view of six platform components at /health:
Cell Ingress, Control Plane, Database Proxy, Mail Relay, Deploy Pipeline, and Alert Bus.
A component is healthy only after a scheduled check exercises the path real traffic uses.
A running process, listener, or Kubernetes object is not enough.
Fail-closed states
Component results are healthy, unhealthy, or unknown. Missing synthetic configuration, a crashed or timed-out check,
and evidence older than its stale threshold are never shown as healthy. The aggregate
returns HTTP 200 only while all six checks are fresh and healthy; otherwise it returns
HTTP 503 while remaining responsive from its in-memory cache.
Public endpoints
GET /health— aggregate plus all six stable component keys.-
GET /health/components/<component>— one cached component result. -
GET /health/synthetic— the exact control-plane marker used by the ingress check. -
GET /health/ready— the Kubernetes readiness view of the control plane. It returns 503 only on a confirmed unhealthy measurement; stale, unknown, and never-checked all return 200, because "we cannot say" must not remove the last pod from service. Use the component route above, not this one, for monitoring.
Responses use Cache-Control: no-store. A per-component healthy marker is
present only on a fresh healthy result, so external keyword monitors reject wrong-content
responses rather than trusting HTTP 200 alone. The status page runs outside the cell, so
a cell outage cannot hide itself.
What public health never contains
Health output is platform-wide and deliberately generic. It does not contain tenant or resource names, credentials, internal addresses, target URLs, queue names, image references, pod identities, or raw dependency errors. App and database lifecycle status is a separate resource surface and is not inferred from these platform checks.