> ## 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 Console: Live-Test and Debug Scout Workflows > Test Scout workflows during development with the Console. Run real payloads, inspect block-by-block output, and catch errors before deploying. The Console lets you test a workflow during development by running it directly in the canvas with real input and inspecting each block's output — no production deploy needed. It's the fastest feedback loop you have while building, and the primary tool for catching problems before they reach real users. ## Opening the Console In the workflow canvas, click the play icon (▶) in the top toolbar. The Console opens on the right side of Studio so you can see your workflow and its output at the same time. Type or paste an input payload, click **Run**, and watch each block execute in order. ## What the Console Shows You Running a workflow in the Console gives you a full picture of the execution: * **Input payload** — the JSON you submitted, so you can verify its shape * **Block-by-block output** — each block's result in order, revealing exactly where data transforms or breaks * **Final output** — the complete response your workflow returns * **Timing per block** — how long each block took, helpful for catching slow LLM or API calls * **Errors** — failure messages and which block triggered them The Console is built for live, interactive development testing. [Logs](/workflows/logs) display historical production runs instead. Reach for the Console when you're actively building; reach for Logs when you're triaging what already happened in production. ## What to Check in Each Test Run Run these four checks before moving on from a test: 1. **Input payload shape** — confirm the input matches what your blocks expect. Mismatched field names cause silent downstream failures. 2. **Block-by-block output** — review each block. Empty or `null` results where you expected content show you exactly where to investigate. 3. **Final output schema** — verify the last block returns the fields your consumer needs, especially if you're exposing the workflow as a tool. 4. **Errors and timing** — watch for error statuses, and check timing. A slow LLM block may signal a prompt or model config problem. ## The Debug Loop When something is wrong, work through this cycle to isolate and fix it: 1. **Run with realistic input** — use data that resembles real users, not a toy example 2. **Inspect the first failing or noisy block** — click into its output to see what went in and what came out 3. **Fix the block config or template** — adjust the prompt, logic, or field reference 4. **Re-run with the same input** — verify the fix addresses the broken case 5. **Re-run with edge-case input** — test empty strings, missing fields, or odd formats If the same input fails in the Console but succeeds in production [Logs](/workflows/logs), check your [environment](/workflows/environments) — config values like API keys, model selection, or variables may differ between development and production. ## Console Tips Save reusable JSON snippets — happy path, empty input, unusual characters — so you can re-run them after every change and catch regressions early. Pass missing required fields or unexpected values so your error-handling blocks actually get exercised, not just the success path. When a workflow is used as a [tool in Copilot](/agents/copilot) or via the API, output field names form part of your contract. Rename them here, not after deploy. A quick Console run after a prompt or logic change takes ten seconds and saves debugging a production incident later. ## Next Steps Analyze production run history and triage failures after they happen. Understand how development and production config differences affect runs. Run workflows from the REST API or SDKs once they're ready for production. Understand block types and their failure modes to debug traces faster.