Why your sidebar is shorter than this one
The dashboard renders only the screens your deployment can answer. What decides that, and how to get a missing one back.
On this page
You read a page about the Cache surface, opened your dashboard, and there is no Cache entry in the sidebar. Nothing is broken. The navigation is computed from what your instance can answer, so two installs of the same binary show different sidebars.
Thirty-seven entries exist in the shipped navigation. A tokentriage demo instance renders
thirty-five of them. A config file carrying upstreams, a tier and dashboard.enabled: true
renders twenty-three. Both numbers come from resolving the shipped navigation against capability
payloads captured from those two running binaries.
The instance advertises, the sidebar follows
On load, the web app asks the server what it can do. The answer is a capability document, and every navigation entry is a small rule over it. That rule has three outcomes, not two.
| Outcome | What you see | What it means |
|---|---|---|
| enabled | a normal entry | the subsystem is wired and the screen will answer |
| disabled | a greyed entry with a reason | the subsystem is real here, but something it needs is not granted |
| absent | nothing at all | this deployment has no such subsystem |
The third outcome is the one to internalise. There is no greyed-out teaser inviting you to upgrade, and no entry that leads to a screen apologising for itself. If a subsystem is not part of your deployment, its screen is not part of your dashboard.
Budgets is the entry that uses all three. Define no budgets and it is absent. Define budgets
without granting enforcement and it is present, disabled, and carries enforcement not granted
as its reason. Grant enforcement and it is a normal entry.
What each setting brings with it
Most of the difference between a long sidebar and a short one comes from six settings. Turning one on can add several entries at once.
| Turn on | Entries it adds |
|---|---|
analytics.enabled and its leaves |
Cost · breakdown, Chargeback, Recommendations, Realized, Forecast, Cost · measurement |
cache.enabled |
Cache |
governance |
Governance, Governance · limits, Governance · health |
alerts |
Alerts |
a budgets: entry |
Budgets |
an instances: peer |
Fleet, Instances |
Each cost surface is gated on its own leaf rather than on analytics as a whole, because
“analytics is off” and “analytics is on and the forecast is off” are different states and the
sidebar reports which one you are in. Chargeback is gated on the count of configured
reports rather than a boolean, so analytics with no reports defined does not offer a page with
nothing on it.
The twenty-three entries a minimal instance renders come from what the dashboard composes unconditionally: the read model, the live stream, the control plane, the anomaly detector and reconciliation. Everything else in the list above is opt-in.
Two of those unconditional entries are worth a second look, because a nav rule that says yes is
not a promise that the screen has anything on it. Evals · annotate renders wherever the read
model is on, and the queue behind it offers work by strategy. The selector arrives set to
hard_cases, which ranks rows a judge found hard, and hardness means a judge that declined or a
panel that split. A deployment running the default pointwise-bool grader produces neither, so
the claim comes back with an empty list at HTTP 200 and the screen reports that it had nothing to
offer. That is an answer about your traffic and not a broken screen; switch the selector to
starved_segments, which ranks segments by how few human labels their gold set holds, and work
appears. Quality · judges renders on the same rule and stays at validation_state: empty
until a judge subject on your ledger carries human labels.
Collect the labels a judge is measured against is that queue end
to end.
Ask the instance what it advertises
The capability document is served before authentication, so you can read it from anywhere that can reach the admin listener:
$ curl -s http://127.0.0.1:9090/tt/api/v1/capabilities
{"api_version":2,"engine":{"version":"dev","mode":"ledger","pricing_snapshot":"litellm@2026-07-14#179affb"},"features":{"index":true,"stream":true,"control_plane":true,"replay":false,"budgets":{"defined":0,"enforce_granted":false},"alerts":false,"anomaly":true,...Read it against the table above. "alerts": false and "budgets": {"defined": 0} in that
capture are why neither entry rendered. It also carries the engine’s mode and pricing snapshot,
which is what the two chips in the dashboard header are showing you.
Why the sidebar is computed rather than fixed
A fixed navigation has to choose between two failures. Either it lists everything and several entries lead to a screen that cannot answer, or it lists a subset and hides features that some deployments do have.
Computing it from an advertisement avoids both, and it makes one more thing possible: the capability document is the same read the surfaces make, so the sidebar cannot promise a screen that the server would then refuse to serve. The pattern is borrowed from Jaeger’s UI, which gates its own features on a backend capability read.
The cost is this page. A computed navigation means documentation cannot show one canonical sidebar, which is why the surface index states the condition for every entry rather than only its route.
Moving around
Three things are worth knowing once you have found your screens.
The command palette. Cmd/Ctrl+K anywhere jumps to a surface, a saved view, or a request id. It is the fastest way to reach a record whose id you have from a log line or a support ticket.
The URL is the state. Filters, groupings, sort order, selected columns and the time window all live in the query string, so a filtered explorer view is a link you can paste to a colleague and they will see what you see. Saved views are the durable form of the same idea.
Pinning promotes. A saved view marked as pinned appears in the sidebar under your other entries, and following it applies the whole frozen query rather than only its text filter. Share a view covers saved views, sharing and scheduling.
When an entry you expect is missing
Work through it in this order.
- Read the capability document for the feature you expect. If the field is false or absent, the subsystem is not composed and no amount of clicking will help.
- Check the setting in the table above, then confirm it is in the running config rather than a file you edited but did not apply. Settings serves the running config verbatim.
- Restart if the setting is one that needs it. Composition happens at boot: turning on analytics, the cache or governance in a config file requires a restart before the entries appear.
- Type the URL anyway. Most surfaces render honestly when reached directly, reporting that their subsystem is off rather than 404ing. That is a fast way to confirm which of the two situations you are in.