Inspect individual runs for latency, token usage, tool calls, errors, and the identifiers you need to report a problem.
A run is one model call: the agent receiving a turn, deciding what to do, calling tools, and producing a response. One user message can produce several runs when the agent gathers data before answering.
Logs is the record of those runs, and it is where you go when something is slow, expensive, or broken. Where Conversations shows what the person saw, Logs shows what the runtime did.
Arriving from a user or conversation adds a chip for that context, which you can clear to widen the view without losing your other filters.
The drawer groups everything recorded about a run into four sections.
Status, model, reasoning effort, start and completion times, and — on failures — the error code. A run with no model shown used the project's default.
| Field | What it tells you |
|---|---|
| Time to first chunk | How long the person waited before text appeared |
| Total latency | Full duration from start to completion |
| Input tokens | Tokens consumed by the prompt, context, and tool definitions |
| Output tokens | Tokens the model generated |
| Total tokens | Input and output combined |
| Credits | Credits charged for the run |
Time to first chunk and total latency answer different questions. A high first-chunk time means the agent was thinking or calling tools before it said anything, which is what people experience as slowness. High total latency with a fast first chunk is usually a long answer, and rarely a complaint.
Links to the user and the conversation this run belongs to, so you can move from a technical symptom to the human situation around it.
The tool names the run called and the kinds of generated UI it produced. This is the ground truth for whether a tool was actually used — more reliable than reading the response and inferring it.
Run ID, request ID, SDK version, and protocol version.
Include the request ID when reporting a problem to HeroUI support. It identifies the exact run in our systems and turns "the agent failed yesterday" into something diagnosable.
Filter Status to Failed over the window where the problem appeared. If failures cluster at one point in time rather than spreading evenly, compare that moment against your deploys and prompt changes.
Open a failed run and note its error code. Then check whether the other failures share it — one repeated code is a single bug, while scattered codes usually mean an upstream dependency.
Look at Components and tools. A run that failed without calling the tool you expected is a configuration problem: a toolkit that is off, an MCP server that is unreachable, or a client tool that never registered.
Follow the conversation link. The transcript shows how the failure surfaced — sometimes a "failed" run still produced a usable answer, and sometimes a completed one did not.
Clear the status filter and open a successful run for the same model. Differences in token counts or tool calls usually point at the cause: an oversized context, a tool that stopped returning data, or a model change.
Latency rising with no code change. Compare input tokens against an earlier run. A growing knowledge base or tool set enlarges every prompt.
A tool stopped being called. Check the MCP server's status and its allowlist. An unreachable server contributes no tools and the turn continues without them, so the agent simply appears to have forgotten the capability.
Credits higher than expected. Sort through runs for high total tokens. Large tool results and long conversation histories cost more than long answers do.
Runs stuck in Pending. The run was accepted but never started streaming. Check for a failing token endpoint or a revoked API key.
