Skip to main content
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:
FieldDescription
Run IDA unique identifier for the run. Use this when reporting issues or correlating logs with API responses.
TimestampWhen the run started, in your local timezone.
TriggerWhat initiated the run — a webhook, a schedule, a Console test, or an API/SDK call.
Statuscompleted, failed, or running.
DurationTotal time from trigger to final output, in milliseconds.
EnvironmentWhich 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.

Watch duration trends

A block that normally completes in 200 ms jumping to 2 s is a signal worth investigating — even if runs are still succeeding.

Track failure signatures

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.

Pair with History

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.

Verify after deploys

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

Environments

Roll back to a previous revision when logs show a promotion introduced failures.

Running Workflows

Use the Console to reproduce failures from logs with controlled inputs.

Creating Workflows

Structure your workflow to make failures visible and easy to trace in logs.

Blocks

Understand block types and their failure modes to debug traces faster.