Runs & Traces
Find a specific execution, inspect everything attached to it, and follow the agent's work span by span.
Run Logs
The Logs tab in your project shows a chronological list of all agent runs. Each row displays the run status, agent name, deployment, duration, token count with estimated cost, and when it was queued. The table updates every few seconds.
Filtering Runs
Use the filter bar at the top to narrow down runs:
| Filter | Description |
|---|---|
| Status | Filter by one or more statuses: queued running completed failed cancelled |
| Date Range | Select a preset such as 24h, 7d, or 30d, or choose a custom range. |
| Deployment | Show only runs from a specific deployment. |
| Search | Search run content, or filter with an expression such as context.customer == 'acme'. The sparkle button turns a plain-language request into a filter. |
input.amount >= 40), and the agent output (output.priority == 'high'), and can be combined with and, or, and not. Store stable metadata such as user IDs, session IDs, request types, or workflow versions in middleware so you can isolate related runs later. The question-mark icon in the search field lists the full syntax.Inspecting a Run
Click a row in the runs table to open its detail view. The detail page combines run metadata, request and response data, context, and the execution trace.
Run Header
- Run ID and status: identify the execution and whether it completed, failed, or is still in progress.
- Connector: see which connector triggered the run.
- Triggered by: follow the parent-run link when another agent started this execution.
- Duration: inspect total execution time, updated live for in-progress runs.
- Token usage: open the tooltip for the token breakdown and estimated cost.
Run Sections
Use Run Again to trigger the same agent with the same input after a fix. Queued and running executions also provide a cancel action.
Execution Traces
A trace breaks a run into a hierarchical tree of spans. Each span represents one operation, such as an LLM call, tool invocation, middleware hook, or sub-agent execution.
Span Types
| Icon | Span Type | What It Represents |
|---|---|---|
| LLM | A logical language-model step with its prompt, response, and reasoning when available. | |
| LLM Call | A physical provider request. Retries appear as subsequent requests with backoff details in metadata. | |
| Tool | A tool invocation with the arguments it received and the value it returned. | |
| MCP Tool | A call to an external MCP server, including the server, tool, arguments, and response. | |
| Middleware | A before or after middleware hook and the data flowing through it. | |
| Sequential | A sequential orchestration step containing child spans for each agent. | |
| Run / Step | The top-level run or one iteration of the agent loop. |
Reading a Trace
Child spans are indented beneath the operation that created them. For each span, inspect its status, duration, inputs, outputs, and metadata. LLM spans can also include Thoughts when the provider returns reasoning content; configure that behavior with reasoning_effort in agent configuration.
- Status: whether the span finished successfully or encountered an error.
- Duration: how long the operation took.
- Inputs and outputs: the data that entered and left the step.
- Metadata: model names, retry counts, and tool error details.
Trace Example
Here the request passes through before middleware, the model chooses calculator.add, the model turns the tool result into a final answer, and after middleware completes the run.