Flicker publishes a cached view of six platform components at /health:
Edge Relay, Cell Ingress, Control Plane, Database Proxy, Mail Relay, and Deploy Pipeline.
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 edge and direct-ingress checks.
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 component monitors reach these routes
through a configured direct cell-ingress origin, not through Edge Relay. That keeps all six
status reads reachable during an edge outage while the independent public black-box
monitors continue to test the same edge path customers use.
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.