Status and provenance

The console is built around one rule: it never shows a health or a number that nobody measured. This page explains how that rule appears on screen and in the API, so you can tell healthy from not measured, and a measured figure from a derived one.

Three kinds of value

Each value on a page carries a provenance, drawn next to its source:

An absent value is never drawn as zero, empty or green.

Verdicts

A page that was built for an endpoint which had no page opens on a status indicator: one dot, one headline, the source and the time, and an explicit absent form with the reason (flutter/lib/core/widgets/indicator.dart frames it). Tones run from ok, info and neutral to warn and danger.

Green is earned. An empty list has nothing to judge, so it is neutral, not a pass. For example, the Client instances tile is neutral when there are no instances, green only when every instance is ready, and amber otherwise.

Time

Timestamps belong to the data, not to your browser. A page header’s “as of” time is parsed from the payload (for example generated in /api/dashboard), not stamped with the current time. Agent run rows show the run’s own timestamp in the same format, prefixed with the date when it was not the same day. The console no longer computes “3m ago” from the browser clock, because that made a stale history look fresh.

Not measured is a real answer

Many endpoints distinguish nothing found from could not look. Read the difference, because the fix is different:

The API convention behind it

Every report endpoint on the console follows one convention (writeJSON in api.go):

• A report GET that could not read its source answers 200 with source: "unavailable" and complete: false. It does not answer 503.
• A 503, then, means the console (or the edge in front of it) did not answer. That is a different fact.
• The web client has one ladder: 401 sends you back to sign in; any other non-200 is an error.

The reasons are in the code: a 503 is what the edge emits when the console is down, so the two would be indistinguishable; a 503 tells intermediaries to retry a condition that no retry can fix; and a non-200 would throw away the gap report the body carries.

The CRUD routes (/api/connections and its siblings) are not reports, and may answer 503 when the registry cannot be written.

The Metrics page

DevEx › Metrics reads GET /api/metrics. It reports only what the console process can measure:

• process: goroutines, heapBytes, sysBytes, gcCycles, cpus, gomaxprocs, uptimeSecs, goVersion, and on Linux openFDs and rssBytes (source: "runtime");
• workloads: the tracked Deployments and DaemonSets, with total, degraded and complete (source: "kube-api");
• utilisation: live CPU and memory, from metrics.k8s.io when it exists, else from the kubelet Summary API through the API server’s node proxy (labelled kubelet-summary).

It lists what it does not measure in unmeasured: an availability SLO (it needs a Prometheus time series), network throughput (it needs node interface counters), and per-tenant ClientInstance workloads (the panel covers the platform namespaces only). There is no uptime percentage on the page, because nothing measures one.