Debug a failed run

This guide is for authors whose automation failed in production. It takes you from the failed run to a published fix and the run picked up again. Runs describes the run page in full. For many runs with one cause, see Recover failed runs.

RunsFailed runstatus: Failed

RunsFailing stepInput and Output

EditorOpen in the editorThe run on the canvas

EditorFix the blockChange what broke

EditorRun from hereSame data, writes held

EditorPublish and resumeThe run carries on

From a failed run to a published fix. Run from here tries the fix on the exact data that failed.

1. Find the run

Open Runs. Failed runs are gathered into failure groups at the top of the list, one per cause. Select a group, then use Previous and Next to go through its runs.

To see one automation’s runs, choose Investigate runs from its menu in the Automation list, or use Runs in the editor header. To see a flat list of every failure, set runs to Ungrouped and status to Failed.

2. Find the failing step

Open the run. The header says Failed at the block that failed and why. Click Show step to select it in the execution timeline.

The message is as specific as Lainstack can safely be. A failed outside call says what the platform knows, such as “The server responded with 503”, and never quotes what the other system wrote. See Failure messages.

Look at the step’s Input and Output. Most failures come from one of these:

• A value is missing. A setting maps a block that did not run on this path. Condition and Switch fail rather than guess when a compared value is missing. Map from a block every path passes through, or branch earlier.
• The data changed shape. An API or caller sent something the schema did not expect. The input shows what really arrived.
• The other system refused. HTTP Request fails on any status outside 200 to 299. The step shows the status; see Call an outside API to handle it.
• A connection expired. Check its status under Connections.

The block’s reference page lists its traps and error codes.

For an AI Agent step, each turn in the run’s details also shows Text: what the model wrote after that turn’s tool calls. Its thinking is not shown.

If your workspace has an agent, the Ask action next to the failure, named after the agent, hands the failure to it in chat.

If the header warns that part of the record could not be saved, see Incomplete records.

3. Open it in the editor

Click Open automation. The editor opens on that run: the run bar names it, blocks show how they did, and blocks the run never reached are dimmed. A Changed mark means a block was edited since this run, so its setup on the canvas may not be what ran.

Click the failed block. Its Run tab shows the failure and the input it failed on.

4. Fix and test

Change what caused the failure, then click Run from here on the failed block’s Run tab. It runs your draft from that block on the same data, with earlier blocks reused and writes held. Check that the block that failed now succeeds, and read the result on the Run tab of the blocks after it.

Reads in this run are real calls. Writes are not sent, and the blocks after a held write run on a stand-in, not a real response. A pass tells you the fix works on this data, not that the write would be accepted.

5. Publish and resume

Click Publish. New runs use the fixed version.

The run that failed stays failed until you act on it. If its work still needs doing, return to it on the Runs page and resume it. Resume on live continues it on the version you just published. A resume is real: from the block it starts at, writes write and emails send. See Recover failed runs.

If it does not need redoing, dismiss it with a reason.

Next

• Recover failed runs
• Runs in the editor
• Put a person in the loop: let a person fix bad data instead of failing the run.