Console
Console
Watch what the Gateway did, and manage what can call it. Eight surfaces, grouped by whether you are looking or acting.
The Console lives at /dashboard. Every surface has its own URL, so a link to the thing you are looking at is a link somebody else can open, and the browser back button works. The sidebar, the header title and the command palette all read one list — src/app/dashboard/nav.ts — so a surface cannot exist in one and be missing from another.
The grouping is the whole idea. Monitor is read-only: what happened, what it cost, what broke. Operate is what this account can reach — a credential, the model catalogue behind it, a callback. Account is you and your organization.
The surfaces
| Surface | Path | The question it answers |
|---|---|---|
| Overview | /dashboard | What has this account done lately, and what is left of the allowance? |
| API | /dashboard/api | Is the Gateway working — how many requests, how slow, how many failed and whose fault? |
| Usage | /dashboard/usage | What did it cost, on which models, and is that going up? |
| Logs | /dashboard/logs | Show me the individual requests, and the whole trace row behind one. |
| API Keys | /dashboard/keys | Which credentials exist, what can each one do, and is anything still using it? |
| Models | /dashboard/models | What can this key call, at what price, in which tier? |
| Webhooks | /dashboard/webhooks | Where should events be posted when they fire? |
| Settings | /dashboard/settings | Who is on this organization, and which model do calls default to? |
The pages
API monitor
Request counts, error rate, true p50/p95/p99, and failures bucketed into six classes.
Usage & cost
Tokens and dollars by model, key or runtime, priced at the moment they were spent.
Logs
One row per Gateway request, newest first, with the full trace row behind it.
API keys
Minting, scopes, binding, rotation, and how a key is stored.
Models
The rate card for this account: what your key can call, at what price, and what “auto” picks.
Webhooks
Events, payload shape, the HMAC signature, and the retry schedule.
Settings & billing
Profile, organization members and roles, and the default model.
Everything that reads the ledger is org-scoped
Overview, API, Usage, Logs and API Keys all read the whole organization and narrow with a filter, rather than starting from one runtime and widening. That is the right default for two reasons: an organization is the unit a bill and an incident belong to, and most accounts have no runtime at all now that the agent-VM runtime is retired.
Webhooks is the exception. An endpoint is stored against a runtime row, so that surface is scoped to the one selected in the sidebar.
Command palette
Press ⌘K (or Ctrl+K) anywhere in the Console. It opens a search box over two groups: Navigate, which is the eight surfaces above, and Runtimes, which lists any legacy agent row on the account and is empty for everyone who arrived after the agent-VM runtime was removed.
Matching is a plain substring over the label, the hint and a keyword list, so p95 finds the API monitor and secret finds API Keys. Arrow keys move, Enter runs, Escape closes.
supabase/migrations/20260908_api_keys_and_request_traces.sql. On a deployment where that has not been applied, both say so plainly rather than rendering an empty dashboard that looks like zero traffic.The Console does not replace the response headers. Everything the API monitor knows about a request was written from the same code path that set x-lobstack-request-id on the response, so a caller and an operator are looking at the same event from two sides. That mapping is set out on the API monitor page.