Health reporting

One document, one code path. The balancer, the dashboards and this page all read the same JSON, so there is no situation where the page claims health the balancer disagrees with.

Current

reading…

Fetched by your browser just now

Round trip

—

Your client to this node, including TLS resume

Fields

serving: Boolean. false means the node is draining: it finishes in-flight responses but must receive no new requests. A balancer that keeps sending traffic to a draining node will see rising latency, not errors.
refilling: Boolean. The cache is cold after a restart or a disk replacement. The node is healthy, but the hit ratio is low and origin egress is elevated. Weight it down rather than removing it, otherwise it never warms.
release: Build identifier of the running code. During a staged rollout the fleet reports two different values; that is expected and not an alarm.
tier: Placement label. Used to decide which origin shield the node refills from. It is not a geographic promise.
cache.hit_ratio_5m: Fraction of responses served without contacting the shield, over a five minute sliding window. Below 0.6 on a warm node is worth investigating; below 0.3 usually means a cache key change shipped.
cache.objects: Distinct objects currently resident across both tiers. Counts objects, not segments, and does not include partial objects awaiting completion.

Status codes from the endpoint

200: Document follows. Read serving; a 200 alone does not mean "send traffic here".
429: You are polling too fast. The endpoint is rate limited per source address and returns Retry-After. One poll every two seconds is plenty.
503: The node is up but has decided it cannot serve — usually a failed disk or a refill path that cannot reach the shield. Treat as hard removal.

Do not build alerting on the HTML page. It is a rendering of the JSON and its markup changes without notice; the JSON field names do not.

Polling etiquette

The endpoint is cheap but not free: it reads counters and touches no disk. Polling from a monitoring system at one or two second intervals is fine. Polling from every viewer's browser is not, which is why the rate limit exists and why this page fetches exactly once per load.

If you are monitoring the delivery footprint as a whole rather than this node, poll the balancer instead. A single node reporting serving: false during a rollout is routine and should not page anyone.