Skip to content

Console

Logs

Every request that reached the Gateway, newest first, with the whole trace row behind each line.

/dashboard/logs is the request log. One row per call that reached the Gateway — the time, what was asked for, what served it, tokens, cost and status — and clicking a row opens the receipt the trace stored for it. Newest first, fifty rows a read, with a Load 50 older button underneath.

It is the same ledger the rest of the Console reads. Overview shows the newest ten of these rows and Usage totals them, so a figure that differs between the three is a bug rather than a different definition.

This used to be a runtime log, and is not one nowUntil the agent-VM runtime was retired this surface rendered lines a process on a machine wrote about itself — provisioning stages, rebuild attempts, health-check failures. Those writers are deleted and the table they wrote to was dropped. Nothing here is a log line somebody chose to emit; every row is a request that was served or refused.

Filters

Four, and each one is a query rather than a client-side sift, so a filter applies to the whole period and not to the page you happen to have loaded. All four live in the URL: “the 5xx on the production key, last 30 days” is a link you can paste into a thread.

FilterOptionsUse it for
API keyAny key on the org by name, or No key · sessionWhich client caused this. A row with no key was a browser session or a legacy runtime token.
ModelEvery model that appears in the window, asked for or servedOne model's failures, or checking where the router actually sent things.
StatusAll, Succeeded, Failed, 4xx · caller, 5xx · usThe distinction that matters in a postmortem: whose fault it was.
Period7, 14, 30 or 90 daysHow far back the query reaches.

The receipt behind a row

Expanding a row shows every field the trace stores, in five groups, and nothing that is derived or estimated. A failed request puts its status, error class, error code and the provider’s own message at the top, with one line saying whose fault the class implies.

GroupFields
RequestRequest id, exact timestamp, endpoint, streamed or buffered, client
RoutingRequested model, served model, whether the router changed it, provider, mode
Cost and sizePrompt, completion and total tokens, and the cost frozen at request time
LatencyTotal round trip, and time to first token on a stream
Attributed toThe API key, and the legacy runtime row if the call came through one

The request id is the value that came back in x-lobstack-request-id on that call, which makes a support thread a lookup rather than an interview.

A dash is not a zeroAn unpriced request shows its cost as —, and a banner above the table counts how many of the rows listed are in that state. It means the meter could not price the call — usually a model key the registry does not know — not that the call was free. The same rule runs through the ledger, the headers and the stream frame: Metering & cost.

No savings figure appears here

Deliberately. The trace table records what a call cost and not what it was measured against, so it cannot tell a named baseline — you asked for a model and we served a cheaper one — from a plan_ceiling one, where you sent auto and the comparison is the dearest model your plan allows. Those are different claims, and subtracting two numbers here would present the flattering one as the other. The priced ledger carries the reason, and the response carries it on the call itself.

Two states that are not an empty listOn a deployment where the request-trace migration has not been applied the page says so rather than rendering zero rows, and a failed refresh keeps the last successful read on screen with a line saying the rows are stale. “Nothing happened” and “we could not look” are never drawn the same way.
Lobstack

One key over every frontier model, a receipt on every call, and an agent that waits before it changes anything.

© 2026 LobstackAll rights reserved  Status