> Source: https://builder.ema.ai/v2/testing-operations/debug-logs > Title: Debug Logs # Debug Logs Debug logs give you a complete, structured record of what an AI Employee (AIE) did on a single run — every node that executed, in order, with its status, inputs, outputs, the LLM prompts and responses behind it, the Tools it called, and any errors. When a response is wrong or a run fails, the debug logs tell you exactly where and why, without re-running or guessing. Every [run](/builder/v2/testing-operations/testing-ai-employees) records this trace automatically. You reach it from the run detail page, and the same data is available over the API. ## Opening a run's debug logs Each run has a detail page that opens from any list of runs — the AI Employee's run history, the chat or dashboard surface, or a result row in an [evaluation](/builder/v2/testing-operations/evaluation) (each eval result links back to the workflow run that produced it via its `workflow_run_id`). The run detail page has two tabs: - **Details** — the run summary, input, output, and the full step trace. This is the debug log. - **Activity** — the audit activity for the run. At the top, a summary shows the run's **duration**, total **tokens**, **trigger** (how the run was started), workflow **version**, and **started** / **completed** timestamps. The run's status (`pending`, `running`, `paused`, `completed`, `failed`, or `cancelled`) is shown next to the title. An admin can abort a `pending`, `running`, or `paused` run from here. ## What the page shows ### Input and output - **Input** — the parameters the run was started with, rendered as expandable JSON with a copy button. Empty when the run took no input parameters. - **Output** — the result returned when the run completed, also expandable JSON with copy. Empty until the run finishes. ### Tool calls Durable, asynchronous Tool calls attached to the run are listed in their own card, and stream live while the run is still in progress. ### Step trace The heart of the debug log is the **step trace** — the ordered list of every node the run executed. Each step is a collapsible row showing, at a glance: - The step number and the node's **status**. - The node **label** (and its underlying node ID). - The **node type** (for example `agent`). - For agent nodes, the **agent-type version** that was pinned and executed — so you can reconstruct exactly which configuration ran, even months later. - **Duration** and, when the step used an LLM, the **token** count. Step status uses these values: Status Meaning Completed The step finished successfully. Failed The step errored. Running The step is currently executing. Paused The step is waiting (for example on a human-in-the-loop response). Pending The step has not started yet. Skipped The step's branch was not taken on this run. > [INFO] > **Duration for paused and pending steps shows as "--".** The wall-clock time for a step waiting on a human includes idle time that isn't real execution, so it's shown as a dash rather than an ever-growing timer. ### Expanding a step Open any step to see its full detail: - **Token breakdown** — prompt, completion, and total tokens for the step. - **Error** — a structured error display when the step failed. - **Input** — what the agent received at runtime, as readable text when there's a clear summary field (like a query or message) or as expandable JSON otherwise. - **Output** — what the agent produced. Rule-validation outputs render as a structured validation report; other outputs render as text or expandable JSON. - **LLM trace** — for steps that called an LLM, the per-iteration trace: the model and provider used, the input messages, the output content, and any tool calls and their results. Tool-call IDs are resolved to human-readable Tool names. - **Code-agent execution trace** — for code-executing agents, the execution trace. - **Integration call trace** — the list of integration (Tool) executions the step made. - **Routing decisions** — the per-edge condition evaluation that determined which branch the run took out of this node. This is how you answer concrete debugging questions: _Which branch did the run take?_ (the routing decisions and which steps are `Skipped`). _Why did the agent answer this way?_ (the LLM trace — the exact prompt and response). _Did the Tool get the right arguments?_ (the integration call trace). _Where did it break?_ (the failed step's structured error). ## Reading the trace over the API The same data backs the UI and is available programmatically: Action Endpoint Get run details `GET /runs/{run_id}` Get the ordered step trace `GET /runs/{run_id}/steps` Get a flattened run trace `GET /runs/{run_id}/trace` Stream a run as it executes `GET /runs/{run_id}/stream` List runs for a workflow `GET /workflows/{id}/runs` `GET /runs/{run_id}/steps` returns the steps in execution order. Each step carries its `node_id`, `node_label`, `node_type`, `status`, `started_at` / `completed_at`, token counts, `input`, `output`, `error`, the `llm_trace`, and `action_executions` (the Tool calls). See the [API reference](/builder/v2/api-reference) for the full schema. > [TIP] > **Debugging without polluting metrics.** Re-run with [test mode](/builder/v2/testing-operations/testing-ai-employees) on to reproduce an issue without making real external calls or counting the run in production [chat metrics](/builder/v2/testing-operations/chat-metrics). The debug log of a test-mode run is just as detailed. ## What's next - [Testing AI Employees](/builder/v2/testing-operations/testing-ai-employees) — produce runs to inspect. - [Evaluating AI Employees](/builder/v2/testing-operations/evaluation) — each eval result links to the run that produced it. - [Launching and monitoring](/builder/v2/testing-operations/launching-and-monitoring) — when a production metric moves, the debug log is where you find out why.