> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scoutos.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow Logs: Debug and Monitor Scout Automation Runs
> Access Scout workflow logs to debug failures, monitor performance, and trace block-by-block execution. Filter by status and date to find issues fast.
Workflow logs give you a complete record of every run — what triggered it, what each block received and returned, how long each step took, and why a run failed if it did. You don't need to add instrumentation or wire up external monitoring to get this visibility; Scout captures it automatically for every execution.
## Accessing Logs in Studio
Open the **Logs** tab in the left panel of your workflow canvas. You'll see a list of recent runs sorted by time, with status, duration, and trigger information visible at a glance.
Click any run entry to open its full execution trace. The trace expands into a block-by-block view that shows exactly what happened at each step.
Logs are scoped to the workflow you have open. To view logs across multiple workflows, use the global Logs panel in the Studio sidebar.
## What Each Log Entry Shows
Every run entry in the log list includes the following fields:
| Field | Description |
| --------------- | ------------------------------------------------------------------------------------------------------- |
| **Run ID** | A unique identifier for the run. Use this when reporting issues or correlating logs with API responses. |
| **Timestamp** | When the run started, in your local timezone. |
| **Trigger** | What initiated the run — a webhook, a schedule, a Console test, or an API/SDK call. |
| **Status** | `completed`, `failed`, or `running`. |
| **Duration** | Total time from trigger to final output, in milliseconds. |
| **Environment** | Which environment the run executed against — development, staging, or production. |
When you expand a run, you also see:
* **Input context** — the full payload passed to the workflow at trigger time
* **Output context** — the structured data returned by the workflow's final block
* **Block-level trace** — the input, config, and output of every block that executed, in order
* **Token usage and cost signals** — token counts and estimated cost for each LLM block
* **Error messages** — for failed runs, the specific block that failed and the error it returned
## Filtering and Searching Logs
Use filters to narrow the log list to the runs you care about. Scout supports filtering by:
* **Status** — filter to `failed` when actively debugging; filter to `completed` when reviewing performance
* **Date range** — set a window around an incident to find the affected runs
* **Environment** — isolate production runs from development or staging test runs
* **Trigger type** — filter to webhook runs, scheduled runs, or manual Console runs independently
When investigating an incident, start with **Status = failed** and the relevant date range. You'll typically find the first failing run within seconds, which gives you the exact timestamp to anchor your investigation.
## Reading Execution Traces
The block-by-block trace is the most powerful part of the log view. Each block entry in the trace shows:
* The **input values** it received from the trigger payload or a prior block
* The **configuration** it ran with (prompt, URL, condition expression, etc.)
* The **output** it produced
* The **duration** of that specific block in milliseconds
* An **error** if the block failed, including any error message from an external API
Read the trace top to bottom — each block's output becomes the next block's input. When a block fails, every block below it in the chain was skipped. The trace makes this clear by marking skipped blocks as such.
## Common Failure Patterns and How to Fix Them
### Input Error
**What it looks like:** The first block in your chain — or an early validation block — fails with a message like `missing required field: ticket_id` or `expected string, got null`.
**Why it happens:** The data coming into the workflow was missing a required field, had the wrong type, or was malformed. This is usually a mismatch between what the caller sent and what your Input block expects.
**How to fix it:**
1. Open the failed run and check the **Input context**. Identify which field is missing or wrong.
2. Trace back to the caller — the webhook payload, the API request, or the SDK call — and confirm it's sending the correct fields.
3. If the issue is a new edge case (a field that's sometimes absent), add a Condition or Stop If block to handle it gracefully before your downstream blocks run.
### Logic Error
**What it looks like:** The workflow completes — all blocks run — but the output is wrong. Or a Condition block routes to the wrong branch unexpectedly.
**Why it happens:** The block received valid data but produced incorrect output. Common causes include a flawed condition expression, a misconfigured prompt, or a template that references the wrong block ID.
**How to fix it:**
1. Open the failed run and expand each block in the trace. Find where the output first diverges from what you expected.
2. Copy the input payload from the run and reproduce the issue in the Console. Paste the same payload and run the workflow in development.
3. Fix the block config — correct the condition expression, adjust the prompt, or update the template reference — and rerun in Console to confirm.
### External Dependency Error
**What it looks like:** An HTTP block, integration block, or Agent block fails with an error from an external service — a `429 Too Many Requests`, a `503 Service Unavailable`, a timeout, or an authentication error.
**Why it happens:** A third-party API or integration returned an error or took too long to respond. This is outside Scout's control but is visible and actionable in the logs.
**How to fix it:**
1. Open the failed block in the trace and read the full error message, including the HTTP status code.
2. For `429` or `503` errors: wait for the dependency to recover, then rerun the workflow. Consider adding a Delay block before the failing step if rate limits are a recurring issue.
3. For `401` or `403` errors: check that the API key or OAuth token configured for that block is valid and hasn't expired.
4. For timeouts: check whether the external service is experiencing degraded performance, and consider increasing the block's timeout setting.
## Monitoring Performance Over Time
Beyond debugging individual failures, use logs to catch performance regressions before they become incidents.
A block that normally completes in 200 ms jumping to 2 s is a signal worth investigating — even if runs are still succeeding.
Recurring failures in the same block type point to a systemic issue — a flaky integration, an LLM prompt that breaks on certain inputs, or a CRM field that's occasionally null.
Cross-reference failure spikes in Logs with revision promotions in History. If failures started after a specific deploy, the revision diff is your starting point.
After every promotion to production, monitor Logs for five to ten minutes. Confirm that the first production runs succeed before considering the deploy stable.
## Next Steps
Roll back to a previous revision when logs show a promotion introduced failures.
Use the Console to reproduce failures from logs with controlled inputs.
Structure your workflow to make failures visible and easy to trace in logs.
Understand block types and their failure modes to debug traces faster.