Skip to content
LiveGriddocs
Deploy

Running it

OverviewThe media planeEnvironmentHealth and status

Health and status

Degraded is not down. What each health surface can and cannot tell you.

Three surfaces answer "is it working", and they answer different questions. Using the wrong one is how a deploy gets called green while nothing works.

The control plane's /health#

Unauthenticated on purpose — a platform health check carries no bearer token.

{
  "status": "ok",
  "version": "0.1.0",
  "mediaPlane": "reachable",
  "checkedAt": "2026-09-10T06:12:44.101Z"
}

status is ok when the media plane answered and degraded when it did not. Degraded is not down: the control plane is still up and can still mint tokens for when the media plane returns. Returning 503 here would take the whole unit out of a load balancer over a dependency it does not own.

The probe itself is a plain GET against the media server's HTTP port, with a short timeout — enough to tell "the process is up" from "DNS resolves". Health checks that hang are worse than health checks that fail.

/public/live#

Is anything on the wire right now. Reads nothing from the database.

reachable: false is not count: 0. Live state and history is the whole argument; the short version is that a console rendering the first when it means the second goes quiet during exactly the incident it exists to surface.

/public/livegrid/webhook/health#

Whether the webhook receiver is configured — that is, whether a signing secret is present. It does not tell you the media server is actually sending events.

If lifecycle rows have stopped appearing and this says configured, the problem is upstream: the media server's webhook URL, or its egress.

Do not use /health to verify a deploy#

Zero-downtime rollover means the old instance keeps answering /health perfectly while the new one builds. A health poll after a push reports success about code that is not running.

Two things actually answer it:

  • confirm a field only the new code emits (version is there for this), or
  • ask the platform which deployment id is live.

And check once, immediately, before sleeping. Most of the time it is already done, and a poll that waits first is a poll that always costs its interval.

Polling without making things worse#

Ask about the specific deployment by id, never "the newest row" — position is not identity. Machine-readable output only; a line number in human-formatted CLI output breaks silently the first time a preamble changes.

And give a poll three outcomes, not two: done, not yet, and cannot tell. An unparseable answer must exit loudly rather than falling through to the sleep branch — a loop that cannot distinguish "not finished" from "I have no idea" can wait forever, and has.

Up nextOverview