Inspect an execution trace
Read an execution's persisted steps, timeline, tool calls, approvals, logs, metrics, and live status events.
Inspect an execution from its input through its final output, including node steps, tool calls, approval decisions, structured logs, and timing. For a running execution, use the live stream model to understand what a reconnect can recover.
Before you begin
You must be signed in and able to access the execution. Start from a row in Executions or retain the execution ID returned when you started the run. Preview IDs are not execution IDs and cannot be opened through the persisted execution stream.
The detail and stream routes return Execution not found when a run does not exist or is not accessible to the signed-in user. This avoids revealing another user's execution.
How trace data arrives
The detail view reads the persisted execution and its related records. The event stream replays persisted node steps first, then tails live events for an active run.
For every persisted step, replay emits a node:start event followed by a node:end event. A terminal execution then emits execution:status and closes the stream. An active execution subscribes to live events and sends a heartbeat comment every 15 seconds so an idle proxy is less likely to close the connection.
Inspect the trace
In Executions, select the run you need to investigate. The header shows a shortened run ID, current status, skill name or version, start time, duration or running, and provider when recorded.
Compare these identifiers with the run you intended to inspect. If the execution is a replay, the header also identifies the source execution.
Read Input Payload to confirm the data submitted to the skill. Then inspect Output Result for the final response.
For an active or failed run, the output can be empty. Use the current status and error banner to distinguish incomplete work from a successful empty result.
Use Planner & Node Graph Trace for the visual execution path, then compare it with Node Timeline. Each persisted row records its step number, node status, node name, start time, and a state snapshot when available.
Trace in order from the first unexpected state. SUCCESS confirms that a node completed; FAILED identifies a failed node; AWAITING_APPROVAL marks a paused decision gate; and SKIPPED indicates that the node did not run on the selected path.
In Tool Calls, expand your investigation around the node that produced the unexpected result. Each entry identifies the tool, action, status, input arguments, output, and error message when present.
Status values distinguish successful, blocked, rejected, and error outcomes. Some outputs add a readable decision explanation, classification reasoning, or rendered Markdown report. Compare the arguments with the tool's schema before treating a tool failure as a workflow-graph problem.
Open Approval Events when the run is PAUSED_FOR_APPROVAL or a tool call is blocked or rejected. An event records the tool and action, decision status, request time, skill name when available, planner reason, and rejection reason when supplied.
If no checkpoint was created, the section displays No approval checkpoints in this execution. Use the dedicated approvals workflow to resolve a pending request; the trace itself is evidence, not the decision control.
Read Structured Execution Logs from the earliest relevant timestamp. Each log can include its level, event, status, duration, and structured metadata. Correlate the timestamp and duration with the node and tool-call entries rather than diagnosing from one message alone.
Use the header duration and the per-log or per-event durations as execution-level and operation-level timing signals. A missing final duration while the header says running means the execution has not reached a terminal state.
For an active run, select REFRESH when persisted detail appears behind the expected state. A live client that reconnects to GET /api/executions/:id/stream receives saved node events before new events.
Terminal statuses are COMPLETED, FAILED, CANCELLED, and STEP_LIMIT_EXCEEDED. When one is reached, the stream sends execution:status and closes cleanly.
Verify your diagnosis
Confirm the conclusion against at least two trace surfaces. For example, pair a failed node in Node Timeline with its ERROR tool call and the matching structured log. For approval pauses, match the AWAITING_APPROVAL step with the pending event in Approval Events.
Troubleshooting
Next steps
Use Recover and export executions for failed, cancelled, or step-limited runs. For aggregate operational signals, continue to Use the Observability dashboard.