> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.meetgail.com/platform/workflows/core-concepts/testing-debugging/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.meetgail.com/_mcp/server.

# Testing & Debugging

> Step through a run one node at a time, stop at chosen nodes, stand in for a node's result, and follow a run's progress from start to finish.

Before you rely on a workflow, you want to see it work. Two features help: a
step-through debugger that lets you walk a run node by node, stop where you
choose, and stand in for a node's result, and run history that shows what
happened during any run. Together they turn "I think this works" into
"I watched it work."

## Stepping through a run

The debugger starts a run and pauses it before the first step. From there you can
advance one step at a time, or let it run to the end. Each time it pauses, you
can see what is about to happen and what just happened.

#### Start a session

Pick a workflow and start a debug session. The run pauses at the very
beginning, before anything has happened.

#### Step forward

Advance by one step. That step runs, then the session pauses again before the
next one, so you can inspect the result.

#### Inspect the pause

At each pause you can see the details below: the input the next step will use,
the output of the step that just ran, and the current values in the run.

#### Run to the end

When you have seen enough, let the session run the rest of the way to a
finish, or stop it to end the session early.

### What you can see at each pause

| At a pause             | What it shows                                                                                                                     |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Next step's input      | The exact values the upcoming step will run with, after any expressions have been worked out.                                     |
| Previous step's output | What the step that just ran produced.                                                                                             |
| Branch decision        | When a [Conditional](/platform/workflows/node-reference/logic-and-flow/conditional) has run, which path it chose and why.         |
| Current values         | All the values available at this point, grouped as node, config, secret, and system. Secret values are shown masked as `*******`. |

> **Note**
>
> Debugging runs a workflow for real. Steps that send messages, place calls, or
> write to other systems will actually do those things while you step through. Use
> test data, or a workflow set up for testing, if you do not want real effects.

> **Note**
>
> A paused session does not stay open forever. If you leave it idle for a while
> (about 15 minutes), it ends on its own. Taking any action keeps it going.

## Stopping at a chosen node

Stepping one node at a time gets slow in a long workflow. Instead, place a
**breakpoint** on the node you care about and run the session: it runs
everything before that node, then pauses just before it, so you can inspect the
input it is about to use.

To place one, open the node's menu (the three dots on the node) and choose
**Add breakpoint**. A red dot on the node's left edge marks it. Choose **Remove
breakpoint** from the same menu to take it off.

![A node's menu, with Add breakpoint and Override... alongside Duplicate, Copy, Test, and Delete.](/_fern-img/809186ee0aec36fceb5dd29c45508faf3cf090fdf0ca4fbf10aaa5a75c15c09b.webp)

![A node with a breakpoint, marked by a red dot on its left edge.](/_fern-img/62eb9ffa334e04ca5c24a5d1a0159da3adb71baaddf607f64ed57a3ee5990ff3.webp)

* Breakpoints belong to the workflow, not to one session. Place them before you
  start a session, and they are still there the next time you debug.
* Everyone in your organization debugging the same workflow shares the same set
  of breakpoints.
* You can place a breakpoint while a session is paused. It takes effect from the
  next time the session moves on.
* A breakpoint works on nodes inside a
  [Sub Graph](/platform/workflows/node-reference/logic-and-flow/sub-graph) or
  [For Each](/platform/workflows/node-reference/logic-and-flow/for-each) too.
  Inside a For Each, it pauses on every pass through the loop.
* The Start node cannot carry a breakpoint, since a session already begins there.

## Pausing when a node fails

If a node cannot run while you are debugging, the session pauses at that node and
shows what went wrong, instead of failing somewhere you cannot see. This happens
when:

* an expression in the node's settings cannot be worked out, such as a reference
  to a value that is not there,
* a value the node received breaks one of its rules, or
* the node itself fails, for example an outside service keeps returning errors
  after its retries.

This pause happens even when you let the session run to the end. What moving
on does depends on why the node stopped:

* **An expression or a rule problem.** The run follows the node's failure path,
  or fails if the node has none. An override you add at this pause is not used,
  so fix the node's settings, or add the override before your next session.
* **The node itself failed.** If you just move on, the whole run fails, even
  when the node has a failure path. You can
  [stand in for the node's result](#standing-in-for-a-node) first instead: add an
  override while the session is paused, then move on.

> **Note**
>
> A node that runs and reports a failure it was built to report, like an HTTP
> Request that gets a "not found" answer, does not pause the session. It follows
> its failure path as normal, because that is the workflow doing its job.

## Standing in for a node

An **override** lets you supply a value in place of what a node would produce or
use, so you can test the rest of a workflow without the node's real effects.
There are two kinds:

| Override        | What happens                                                                                                            |
| --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Output override | Your value becomes the node's result. The node does not run, so nothing is sent, called, or written.                    |
| Input override  | Your value replaces what the node would use after its expressions are worked out. The node still runs, with your value. |

If a node has both, the output override wins and the node does not run.

To add one, open the node's menu and choose **Override...**. Tick **Output
override** or **Input override**, type the value, and press **Save override**.
The output box starts from the shape of the node's result, so you only change the
values. For a node that can fail, the result carries `isSuccess` (`true` or
`false`) next to its `data`.

![The Node override dialog with Output override ticked and a result filled in.](/_fern-img/8ea5c1e1fa4afed9c400e9fe3502d272ad28fa170ade48b132ffd4379213616d.webp)

Some useful ways to use them:

* **Skip a side effect.** Put an output override on a Send SMS or Outbound Call
  node to test what happens after it without contacting anyone.
* **Test a failure path.** On a node that can fail, supply an output that says it
  failed, and the run takes the failure path without a real failure.
* **Skip a wait.** An output override on a
  [Delay](/platform/workflows/node-reference/logic-and-flow/delay) skips the wait
  entirely.
* **Recover from a failed node.** When a session has paused because the node
  itself failed (not because of an expression or a rule problem), add an
  override and move on. An output override uses your value and carries on; an
  input override runs the node again with your value.

Like breakpoints, overrides belong to the workflow and are shared across your
organization. They stay in place, applying every time the node is reached
(including every pass through a loop) until you remove them. They only apply
while debugging; a normal run never uses them.

> **Note**
>
> An input override on a failed node runs the node again each time you move on,
> including its real effects. Remove the override when you are done.

> **Note**
>
> Overrides are stored as you typed them. Do not put a password or other secret
> value in an override.

### Reusing a result from a past run

Instead of typing an output override by hand, you can copy it from a run that
already happened. Run the workflow for real once, then fill a node's output
override from that run, and debug the steps after it as often as you like
without calling outside services again.

* You can copy from any past run of the workflow in your organization, whether it
  was a debug session or a normal run.
* The value copied is the node's last result in that run. For a node inside a
  loop, that is the result from the final pass.
* A result that reported a failure can be copied too, which is a handy way to
  replay a failure path.
* To refresh the value, copy it again from a newer run.

A few results cannot be copied: from a node that never ran in that run, from a
node that produces no result (like a Delay), or a result too large to keep in the
run's history. The run you copy from must also have finished; a session that is
still paused cannot be copied from yet.

## Following a run's progress

Every run, whether you started it by hand or it was triggered, builds up a
history as it goes: a timeline of events you can follow in real time. It records
when the run started, when each step started and finished, which path a
Conditional took, and when the run completed or was cancelled.

This is how you check on a run without stepping through it. You can watch a live
run move along, or open a finished run to see everything that happened and in
what order. If a step failed, the history shows where.

> **Note**
>
> If a step produces a very large output, its entry in the history is shortened
> so the timeline stays quick to load. This only affects what the history
> displays; the full value is still passed on to the next step as normal.

## Related

#### [Timeouts & Retries](/platform/workflows/core-concepts/timeouts-retries)

Understand how a slow or failing step is handled during a run.

#### [Variables & Data Flow](/platform/workflows/core-concepts/variables-data-flow)

Make sense of the values you see at each pause.

> Documentation for Gail, the AI platform for financial services. Learn how to set up GailGPT and Gail Agent to automate customer communications for insurance, banking, and finance.