Runs
A run is one execution of an automation, from its trigger to its last block. Runs in the workspace rail lists the runs in the workspace.
Find a run
Section titled “Find a run”The list is grouped by default, so it stays short. Failed runs gather into failure groups by cause, and every other run gathers by automation and status, such as “Check shipment updates, Succeeded, 12 runs”. Groups and status rows share one list, in the order you pick. Open a row to see its newest 10 runs; with more than that, Show all N runs filters the whole list to them. Search by run, trigger, automation name or failure message.
The runs chip switches between two lists:
| runs | Shows | Filters |
|---|---|---|
| Grouped | Failure groups and status rows in one list. A run stays with its group, so look for a recovered run under its group’s status. | status of the group: Open (default, includes groups being resumed), Resolving, Resolved, Dismissed. Other runs show only under Open. |
| Ungrouped | Every run on its own, newest first. | status of the run, and mode. |
- status in the ungrouped list: Pending, Running, Waiting, Needs review, Succeeded, Failed or Cancelled.
- mode: Live for runs that really happened, which is the default, Draft runs for runs started from the editor with writes held, and Any.
- time: 1h, 12h, 24h, 7d or All. Grouped opens on 7d and counts only the runs in that range; ungrouped opens on All.
- order: when grouped, Last seen (default), First seen or Most runs; when ungrouped, Newest first or Oldest first.
Links from other pages can add chips such as automation, failed block, failure or failure group. Remove one with its cross, or use Clear filters.
A run is named after its automation unless the automation gives it a better name. Add the Set Run Details block to name runs after the record they handle, so they are easy to find later.
The second line of a row shows its reference, when it started and how it came about. Draft marks a draft run and Resume marks a run that picked up a failed one.
Statuses
Section titled “Statuses”| Status | Meaning |
|---|---|
| Pending | Queued, not started yet. |
| Running | Working through its blocks. |
| Waiting | Paused on purpose, for example by a Wait block. The run shows when it resumes. |
| Needs review | Paused until a person acts on an escalation: an approval, a correction or a review. |
| Succeeded | Finished. If the automation ended on a named outcome, such as Approved, the run shows that name instead. |
| Failed | Stopped on an error, and waiting for someone to act on it. |
| Cancelled | Stopped before it finished. |
One status per row
Section titled “One status per row”Each row in the list shows one status: whatever most needs saying about the run now. Once someone acts on a failed run, its row moves on from Failed:
| Status | Meaning |
|---|---|
| Resuming | A resume is queued or running. |
| Recovered | The resume finished without failing. The run itself is still a record of the failure, and it links to the run that picked it up. |
| Failed again | The resume failed too. The run says why, and the new run is the one to act on. |
| Dismissed | Someone decided not to act on it, and said why. It stays failed and cannot be resumed. |
Two others appear on rows without a normal result:
- Not executed: the run never started, because the automation was not published or could not be run by hand. Hover over it for which.
- Agent results, such as Agent: Failed or Change rejected, on runs of an agent.
Read a run
Section titled “Read a run”Open a run to see:
- The header: its status, when it started and how long it took, and a link to Open automation, which opens this run on the canvas. A failed run says which block it failed at and why, with Show step to jump there, and offers Dismiss. A run that was resumed links to the new run with Resumed as.
- Which version ran: a live run names the published revision it used; a draft run names the draft revision it ran. Expand it to see the blocks and connections that version used.
- Calls: links to the run that called this one, and to the runs it called.
- The execution timeline: every step in order with its status and duration. Switch between Actual time and Equal width to see where the time went.
Select a step to see its Input and Output, stacked or side by side. This is usually the fastest way to see why a block took the wrong branch or failed.
Anyone who can read the run sees its values, including read-only roles. Only secrets are held back: a field a block declares secret is hidden, along with tokens and signed URLs.
If the run has an open escalation, the run links to it with Open escalation.
Failure messages
Section titled “Failure messages”A failed run says why as specifically as Lainstack safely can. What other systems write can echo back anything, including secrets, so it is never recorded.
| The failure | What you see |
|---|---|
The block reports a failure it knows about, such as comparison_invalid |
The block’s own message. Its reference page lists its codes. |
| A block that calls nothing outside and holds no connection fails unexpectedly | Its error text, with anything that looks like a secret removed. |
| An outside call fails | What the platform itself knows, for example “The server responded with 503”, “Timed out after 5 seconds”, “Could not resolve api.example.com” or “Could not connect to api.example.com: connection refused”. |
| Anything else, including most model provider errors | Only a short label: Timed out, Network error, Not authorized, Rate limited, Invalid input, Provider error or Internal error. |
A host appears in a message only if the author typed it into the block. One that comes from a connection or from run data is never named.
A short label means Lainstack knows the kind of failure but holds nothing more it can show. To dig further, look at the step’s input, the block’s setup, the connection, and the other system’s own logs.
The Runs page and the run itself show the same message. Failure notices leave the product, so they show only the block’s own message or the short label.
Incomplete records
Section titled “Incomplete records”A warning such as “Part of this run’s record could not be saved: some steps are missing from the timeline.” means Lainstack could not keep everything about the run. The run itself is not affected: its status is true and its effects happened. What is missing is the account of it.
| The warning says | Means |
|---|---|
| some steps are missing from the timeline | Steps ran, but saving the record failed after retrying. |
| some step values were not saved | A block ran, but its values could not be written. |
| some values were too large to keep | An input or output was over the limit of 64 MiB. Nothing went wrong; the value is deliberately not kept. |
| some step details were dropped | Details could not be saved or read, for example because a worker was stopping mid-run. It can clear on reload. |
What to do:
- Do not read a missing step as a step that did not run. Check the other system if you need to know what happened.
- Run from here asks first, because later blocks may get empty values. Choose Run anyway only if the blocks you need were recorded.
- A resume refuses a run like this: “Part of that run’s record was not saved.” Start the work again from its source instead, or dismiss the run.
- If you see this often, tell the Lainstack team, with the run’s reference.
Runs past the retention period are not incomplete. Their values are simply gone, and they say so.
How long values are kept
Section titled “How long values are kept”On the managed service, the values a run recorded are kept for 30 days after it ends. After that, the run stays in the list with its status and timing, and its step values read “Removed by retention.” It can no longer be resumed or used for Run from here.
Fixing a failed run
Section titled “Fixing a failed run”Fix the automation in the editor, try the fix on the same data with Run from here and publish. New runs use the new version. Failed runs do not fix themselves, but you can resume them, one at a time or a whole group, or dismiss them. See Debug a failed run.
A run paused for a correction is different: the person handling the escalation fixes the input there and the run continues.