Inspect individual runs for latency, tool calls, errors, and the identifiers you need to report a problem.
A run is one logical turn: the agent receiving a message, calling tools, and producing a response. It can include several model steps and tool continuations.
Logs is the record of those runs, and it is where you go when something is slow 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 shows status, performance, timing, context, tool errors, and identifiers.
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 |
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 latency 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 the tools and knowledge sources used by an earlier run. A growing knowledge base or tool set can make responses take longer.
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.
Runs stuck in Pending. The run was accepted but never started streaming. Check for a failing token endpoint or a revoked workspace API key.
Run details show server-assigned metadata and the available timing breakdown. The Runs API and exports include metadata and timing; missing historical values are empty objects.
“Worked for” measures elapsed turn time, including model generation, tool round trips, and continuation work. It is not the sum of HTTP tool execution times. Timing intervals can overlap: for example, summary work can run alongside a provider request. Compare individual intervals rather than adding them together. Missing observations mean unavailable data, not zero elapsed time.
To receive notifications when runs start, complete, fail, or are cancelled, configure webhooks and select the events your integration needs.
Admission is elapsed time from submitting the message until the runtime admits the turn. It can include browser preparation, uploads, network time, authorization, and credit admission. It is not model generation time.
New runs include Admission: auth, Admission: rate-limit, Admission: conversation, Admission: admission (the deletion check), and Admission: source spans when available. These show the API checks separately. Provider steps and browser tool work have their own intervals. Spans can overlap; do not add their durations together. These details are also returned by the Runs API.
Worked for remains elapsed turn time. Fast tools alone do not establish why a turn was slow. Include the timing breakdown, model, SDK version, and run ID when reporting latency.
A completed run can still contain a recovered tool error. Open Tool errors to see the tool name, call ID, error code when available, and the bounded error message. These details are included as tool_errors in Runs API responses and webhook run payloads, and in run exports. Older runs without recorded details show no tool-error section.
Stopping a turn cancels that turn, including an admission still in flight. It removes the active prompt from the outgoing queue and pauses queued follow-ups. It does not enqueue another copy of the stopped prompt. Effects already applied by a tool are not undone.
