Recover failed runs

A failed run does not have to stay failed. Once the cause is fixed, you can pick each run up where it stopped, with the work before the failure kept. This guide is for operators and authors handling a batch of failures. To find out why one run failed, start with Debug a failed run.

Testing comes before publishing, so you find out whether the fix works before anything happens for real.

Test a fix

Test fix runs your saved draft on real runs that failed, from the block each one failed at, with every write held. Nothing happens in other systems. Find it on the failure group, or on a selection of its runs.

A failure group with its sample error, Test fix, Resume and Dismiss buttons, the latest test with each run's outcome, and its facts beside the run.

A test picks up to 5 runs spread evenly from the group’s oldest to its newest failure, so a cause that changed over time shows up. If you select runs first, up to 5 of them are added. A group whose runs failed before any block ran, shown as Start, cannot be tested or resumed: start new runs instead.

The Test results section lists each run and what the draft did on it:

Outcome	Means
Passes	The run finished with no failure, and no later block depended on a stand-in. “Would write” counts what was held.
Passes on stand-in outputs	The run finished, but later blocks read a stand-in for a held write. Your fix works on that data; the real call behind it is not tested.
Stopped at a held write	The run finished, but a held write had nothing to pass on, so the blocks after it never ran. They are untested, and this does not count as a pass.
Fails the same way	It failed with the same cause. The fix does not address it.
Fails differently	It got past the old failure and failed some other way, or at another block. The reason is listed.
Not tested	This run could not be tried, for the reason listed.
Running	Not finished yet. Outcomes fill in as the runs finish.

What “passes on stand-ins” means

A draft run never sends a write, so it never gets a real response from one. When later blocks need that response, the run feeds them a stand-in: the block’s pinned output, its last real output, or the plan some blocks give. None of them is a real response.

So “passes on stand-in outputs” tells you the fixed block now works and the rest of the path handles data of that shape. It does not tell you the other system will accept the write, or what it would answer. The summary says it plainly: “so their real calls are not tested”. This is why a run that passes on stand-ins, or stops at a held write, does not count as a pass when you later resume on live.

Reads in a test are real calls, so a read that fails tells you something real.

Resume

A resume starts a new run from where the old one stopped. Earlier blocks are not run again: their outputs are reused. There are two kinds, both in the Resume menu, and both are real runs.

Action	Runs on	Starts at	Use it when
Resume as is	The version each run first ran	The failed block	Nothing in the automation was wrong: a system was down or a connection expired, and it is back.
Resume on live	The current published version	The failed block, or the earliest block changed since the run’s version	You published a fix.

Resume on live needs a published version with your fix, so publish first. A draft is never resumed. A block changed earlier than the failed one moves the start back to that block, and the dialog says how many runs that affects. A block with secret outputs also moves the start back, since its secrets were never stored and cannot be reused.

You can resume from a failure group, which covers every failed run in it, or from a selection of runs. A selection stays within one automation. Up to 1,000 runs resume in one go, ten at a time.

The confirm step

Both actions check each run first and show what will happen:

The Resume on live confirm dialog with the number of runs, the blocks that will run again for real, the test result and a warning.

These blocks will run again for real, with how many runs each applies to.
How many runs start at an earlier block.
Test results: how many runs passed on this version, when a test ran on it.
A warning if live is not tested, below.
Which runs cannot be resumed, and why. The others still go ahead.

When live was not tested

Resume on live warns you when no test speaks for the version it will run. You can still go ahead. It is your call:

Warning	Means
This version has not been tested on these runs.	No test has run for this group.
Live changed since the test, so this version has not been tested.	The test ran on something other than what is live now, such as a draft that then changed.
N test runs stopped at a held write, so the blocks after it were not tested.	Some test runs never reached the blocks after a held write with nothing to pass on.
N test runs passed only on pinned or past outputs, so their real calls are not tested.	Some test runs passed on stand-ins.
Not every test run passed on this version.	At least one test run failed.
This selection was not checked against a test. Open its failure group to see one.	The selection is not tied to one group, so there is no single test to compare with.

What a resume does for real

A resume has real effects. Unlike a draft run or a test, nothing is held. From the block it starts at, every block runs for real: writes write, emails send, deletes delete, and models are called.

Blocks before the start are not run again, and whatever they did stays done.
The block that failed runs again. If it may have done part of its work before failing, check the other system before you resume. A block that was waiting on something it had already sent goes back to checking it and does not send again.
Changes a person already made to that block in an escalation are kept, as long as neither the block nor anything before it changed and the resume does not change its input. Otherwise the block starts without them, and any problem they fixed comes back.
A start moved back to an earlier block repeats the writes from that block on.
A resumed run can pause for an escalation like any other run.

After a resume

The original run stays as the record of what happened, and shows its progress in the list:

Status	Means
Resuming	A resume is queued or running.
Recovered	The resume finished without failing.
Failed again	The resume failed too. The run’s page says why and links to the new run.

The new run carries a Resume label in the list, and Resumed as on the old run links to it. If the new run fails, it joins the group for its own cause, and it is the one to resume next: “This run was already resumed. Resume the newest run.”

When no run in a group is left waiting or resuming, the group shows as Resolved. See Failure groups.

Runs that cannot resume

Message	Why
Too old to resume.	Retention has removed the run’s values, which the resume would reuse.
Part of that run’s record was not saved.	Its record is incomplete, so later blocks could get empty values.
A run cannot start inside a loop. Start at the loop step, or before or after it.	The failed block is inside a loop.
The failed step no longer exists in the live version.	You removed the block. Use Resume as is, or start a new run.
This run failed before any step ran. Start a new run instead.	There is nothing to continue from.
This run was dismissed with its failure group.	Dismissed runs stay failed.
Agent runs cannot be started again from here.	Runs of agents are not resumed.
A draft run can only seed another draft run.	Draft runs held their writes, so they are not resumed. Use Run from here instead.
This run has no published version to resume.	It did not run a published version.

Work with the Agent

If your workspace has an agent, Ask followed by its name on a failure group opens the chat with a sample run attached and a request to find the cause and propose a fix.

The agent reads the runs and stores its findings on the group:

Diagnosis: what it found, shown on the group for everyone.
Proposed change, if it has one: a changed version of the automation. A proposal does not touch your draft. Test the proposal tests it without applying it, with its reads held as well as its writes, so nothing goes to an address you have not seen. A read it holds is never a pass: the run says it stopped there, or that it passed on a stand-in. Apply to draft copies it to the draft so you can review it on the canvas.

The agent can diagnose, propose, test your saved draft and merge groups that share a cause without asking, since those change nothing outside Lainstack. To test its own proposal it needs your approval first, because reads in a test are real calls: the card lists the addresses its blocks would call. It needs your approval for what does:

Dismissing a group needs your approval.
Resuming needs your approval. One card covers a publish and a resume together, so the two happen as one decision. It reads “Publish and resume N runs from” the start block, and lists the change, the test, where runs start, what will run again for real and how many runs cannot resume. Nothing runs until you apply it.

The agent is held to a stricter rule than people on live: it must name the version its test ran, so it cannot resume on a version nobody tested. If the card says “No test yet.” or “Live is not the version that was tested.”, read it before you approve. Dismissing, publishing and resuming need the agent’s write access set to Ask or Smart, and they ask first under both.

Assign a group

The Assigned to menu on a failure group lets you claim the group, assign it to a person, team or agent, or unassign it. It changes this group only.

Picking an agent starts it straight away, with your authority and your approval cards, and nobody has to open a chat. The group shows that the agent is looking and links to its conversation. Assigning the group to someone else, dismissing it or resuming its runs stops the agent.

An agent first in a Set Assignees block’s list starts on a new group by itself after 10 minutes, without your approval cards and with a much shorter list of tools. See When an agent comes first.

Who can do what

Action	Needs
See groups, runs and their values	Permission to read the automation’s runs, such as Workspace viewer
Test fix, resume, dismiss, assign	Permission to run the automation, such as Workspace runner
Run draft, Run from here, proposals, merging groups	Permission to change the automation, such as Workspace operator

These actions are in the app and open to the in-app Agent. External MCP clients and the public API do not offer them.