# Testing & Debugging

> Learn how to test your workflows and troubleshoot issues.

You test a workflow by running it and inspecting the data each step produced. The tools for both live on the canvas.

## Running a Workflow

**A manual run starts from a run point.** Every workflow has one: Glow picks the first eligible step for you and marks it on the canvas, so **Run** always has somewhere to begin.

To move it, right-click the step you want and choose **Set run point**. Or open the arrow beside **Run** in the dock and pick from the **Manual run starting step** list.

Where you put it is a real choice:

- **On the trigger** to exercise the whole workflow end to end, using the trigger's test data.
- **On a step in the middle** while you are building, so you skip the steps before it. Handy when the earlier ones are slow, cost money, or send real messages.

Glow prefers a trigger for the automatic run point. Add a trigger later and the run point moves to it. A step you chose yourself keeps the job until it is deleted or disabled; then Glow picks again. A disabled step cannot be the run point. Enable it first, or pick another step.

The run uses whatever **Testing data** the run-point step holds. A run is only as realistic as that data. **Load latest execution** in the step's **Test & Debug** tab fills it from a real run.

### Running a single step

Hover a step and two controls appear on it:

- **Run:** on a trigger, this tries to fetch live data from the service it watches. On an action step it executes the step.
- **Run with test data:** uses the step's saved **Testing data** instead of going out to the network.

The distinction matters on triggers. A trigger that has not finished deploying cannot poll for live data yet. Glow tells you so and points you at **Run with test data**, which works immediately and is usually what you want while building anyway.

## On-Canvas Setup Checklist & AI Repair

When building or testing a new workflow draft, the **Setup Checklist** sits directly on the canvas to track your progress:

- Connecting required app accounts
- Providing valid test trigger payloads
- Running single-step tests
- Publishing the workflow

### AI Debug Automation ("Use AI to fix")

If an assistant-generated draft or imported workflow fails validation (such as missing a trigger, broken port links, or unbound variable chips), the checklist displays a **Use AI to fix** button.

Clicking it runs an automated diagnostic pass:

1. **Identifies structural flaws:** Scans for orphaned steps, missing inputs, and broken type chains.
2. **Repairs canvas geometry and connections:** Rewires broken links and aligns data sources automatically.
3. **Supplies reasonable defaults:** Configures missing test values so you can run an instant verification test.

## Inspecting data with Executions

When debugging a failing workflow, the best approach is to work backwards from the point of failure.

> After running a workflow, check the **Executions** tab in the app drawer to
> see exactly what data each step produced. This is the fastest way to debug
> unexpected results.

In the Executions tab, you can view the exact JSON payload each step produced. What a step _received_ is the output of the step above it — read it on that step's own Executions tab.

## Visual step statuses

While a workflow runs, each step changes colour to show where the run has got to and how each step finished. You can follow a run on the canvas without opening the execution log.

Hover a step after a run and its tooltip tells you how it ended:

| Tooltip                   | Colour | What it means                                                                                                                                                                                  |
| :------------------------ | :----- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Execution in progress** | Blue   | The step is still running. You will see this longest on steps that wait on somebody else, such as an HTTP Request.                                                                             |
| **Execution succeeded**   | Green  | The step finished and passed its output to the next one.                                                                                                                                       |
| **Execution failed**      | Red    | The step gave up: a 500 from an API, bad credentials, or a workspace out of credits. Unless the step is [set to continue on failure](/build/core-concepts/error-handling), the run stops here. |
| **Execution issue found** | Amber  | Something went wrong without sinking the step. Typically some items in a loop failed while the rest succeeded.                                                                                 |
| **Execution skipped**     | Grey   | The step did not run, usually because a **Condition** or **Switch** sent the run down a different branch.                                                                                      |

Running out of credits shows as **Execution failed**, the same as any other failure, so the tooltip alone will not tell you which one you are looking at. The note below covers what to check.

> **After a credit block, verify recovery with a new event.** Restore the
> allowance, confirm the workflow is **Live**, then send one controlled webhook
> request or inspect the next scheduled occurrence. Confirm that a new run
> appears before treating the workflow as recovered. Missed events are not
> replayed automatically.

### The numbers on a step

Alongside the status, a step carries small counters summarising its history. One shows how many times it has run. When retries are configured, a separate marker shows the retry count. They are a quick read of which step is doing the most work, or failing the most often, without opening anything.

Clear them with **Reset counters** from the [canvas utilities menu](/build/the-canvas/canvas-utilities) once the numbers have stopped meaning anything.

## Debugging code and HTTP steps

If you are using **Code editor** or **HTTP Request** steps, they carry their own debugging aids:

- Use `print()` in a [Code editor](/build/action-steps/code-execution) step to see intermediate values. The step runs Python, and whatever it printed comes back under `result.executionOutput`. Reference it as `{{ 4.result.executionOutput }}`, or read it in the step's **Executions** tab.
- Inspect raw HTTP response headers and status codes directly in the drawer.

## What's Next?

- Follow a whole run, step by step, in the [Execution Log](/build/the-canvas/execution-log).
- Dig into the input and output payloads of a single step in [Step-level Executions](/build/core-concepts/executions).
- Look up an error message you cannot place in [Troubleshooting & Errors](/reference/troubleshooting).