Channel Health

Recent CPU, memory, pressure and disk figures of the account.

Restart and exit facts of the channel's app container.

The block describes the running container when one exists, else the newest container of the channel, live or archived. container_index, container_id, and source name that container. started_at is docker's last start of it, which a restart-policy restart moves forward; restart_count counts those restarts.

Recent builds of this channel that the kernel stopped.

Size, cache-hit percent and top statements of the channel DB.

How long this channel took to answer its recent requests.

Every figure covers the SERVER-SIDE span alone: the edge starts the clock when it reads the request, and stops it when it writes the last byte of the reply. The TCP handshake, the accept queue and the TLS handshake all end before that clock starts, so a stall while the visitor connects is invisible here. The transfer of the reply is inside the span, so a slow visitor link raises the figure. A high figure alone does not prove that the app is slow, and no figure states an end-to-end time.

p50_ms, p95_ms and p99_ms are upper bounds off the histogram edges, not measured durations: 95 of every 100 requests finished under p95_ms. max_ms is the one measured figure among them, and it is the worst request of the window.

window_hours names the scope of the read, so it stays present when the block is not available. It states what the route looked at, and it measures nothing about the channel.

slow_request_threshold_ms follows that same rule: it states the reader's cut and measures nothing, so it also stays present in both states. The cut is STRICTLY ABOVE the figure. The console cannot import SLOW_REQUEST_MS, so the payload carries it and the page states one number with the route.