Is it healthy, and where did the time go
Project 360, transactions, CPU profiles, and the differences between environments.
Project 360
Requests per second, 5xx share, p95, Apdex, components running — then three charts and a per-component table, filterable by environment and window.
Open a project →This used to be an embedded Grafana dashboard. Computing it here found four wrong numbers that an iframe cannot show you, which is the argument for owning them: you cannot read a dashboard's queries from inside one, and a confidently wrong number looks exactly like a right one.
Apdex reports the threshold it used. An Apdex quoted against an unstated threshold is not
comparable to anything — and the boundaries are read off the histogram rather than
constructed, because le="1.0" matches no bucket (Prometheus labels it "1") and a
selector matching nothing is an empty result, not an error.
Transactions
Every operation the project performed — an HTTP route, a SQL statement, a queue poll, an instrumented function.
Filterable by environment, component, producer and window.
Open the transactions table →Two producers measure this traffic, and they disagree by design. Tempo's metrics generator sees spans that were sampled and exported; Beyla's eBPF instrumentation sees every call at the network. For one health check they report 110 calls and 1147.
They are never added, and their latency histograms are never merged — the two use different bucket boundaries, and summing those gives a p95 of 16 seconds for an operation that takes two milliseconds. Filter by producer to compare them.
CPU profiles
Where a service that is serving traffic actually spent CPU, filterable by operation and window.
Profile a running service →The numbers come before the picture. A flame graph cannot answer "is this rendered correctly", because a broken renderer and a genuinely flat profile look identical. The hottest frames are computed server-side as percentages, so a bar that disagrees with a number is checkable — and a failed canvas costs the picture, not the profile.
Self is time in that frame alone, which is where the CPU was. Largest subtree is the biggest single occurrence including everything it called — the largest, not the sum, because summing double-counts a frame nested inside itself and produced totals over 100%.
One frame per level, 283 levels deep, is not a rendering fault. It is a profile with a single sample and nothing to distribute across the width. The page says so and suggests widening the window.
How two environments differ
Which release each environment is pinned to, and how the manifests it produced actually differ.
Compare two environments →Every field difference is classified:
The image, a replica count, a limit, an env value. This is the one to read. Four components on this platform are on different images in staging and production right now.
The value is the environment's own name, a namespace, or a generated name containing them — so it differs by definition and nobody can act on it.
A UID or a resource hash. Differs between any two renders and carries no information about either.
Why bother: diffing one Deployment as raw text gives 40 changed lines, all of which are identifiers, while the real answer is "same image, same replicas, same limits". A page showing 40 red and green lines to say that buries the case that matters.
image, tag, digest, sha and revision never get hash tolerance in that
classifier. An image tag is v1-45db1889 against v1-e8881d0b — exactly the shape of a
generated name suffix — and normalising it would call a genuinely different build an
environment difference and hide the single most important thing this page can show.