Failure groups
A failure group gathers the failed runs of one automation that failed for the same reason. A hundred runs that hit one broken block become one line on the Runs page, with one notification and one place to act.
How runs are grouped
Section titled “How runs are grouped”Two failed runs share a group when all of these match:
- The automation. Groups never span automations.
- The block it failed at. Runs that failed before any block ran group under Start.
- The failure code.
- The message pattern. The message with the parts that differ from run to run taken out: numbers, dates, IDs, quoted values and URL query strings. “Order 1042 was not found” and “Order 2077 was not found” are one pattern.
Only runs that really happened count. Draft runs and tests never join a group. A run that a parent run called fails its parent at the block that called it, so the failure is counted once, on the parent. Cancelled runs do not join.
A group’s row shows the block, the cause, how many runs it holds, the automation and when it was last seen. Its page also counts runs by where they stand, for example “5 waiting · 0 resuming · 0 recovered · 1 dismissed”, and lists when it was first and last seen.
Merging groups
Section titled “Merging groups”The message pattern is cautious, so one real cause can end up in two groups. For failed outside calls, Lainstack keeps the other system’s text out of the record, so two groups can even show the same label. Failures whose text differed stay apart, because they may have different causes.
Groups of the same automation can be merged when they share a cause. Ask your workspace agent to merge them. A merged group lists Includes N merged causes with the reason given, and later failures with those causes join it. Merging does not change any run, and it cannot be undone. It needs permission to change the automation.
Group statuses
Section titled “Group statuses”| Status | Means |
|---|---|
| Open | Runs are failed and waiting for someone to act. |
| Resolving | Resumes are queued or running. |
| Resolved | Nothing is left to act on: its runs recovered, failed again or were dismissed. |
| Dismissed | Someone decided not to act on it, or every run in it was dismissed. |
The Runs page shows open groups by default. Use the status chip to see the others.
A new failure reopens a group
Section titled “A new failure reopens a group”A new failure with the same cause always returns its group to Open, whatever its status, even if it was dismissed or resolved. The group notifies again, and the runs it held keep their state. So dismissing a group does not silence a cause for good: it says “nothing more to do on these runs”.
Move through a group’s runs
Section titled “Move through a group’s runs”Select a group to see its page, with its first run below it. Three ways to get around:
- Previous and Next step through the group’s runs one at a time, under “Run 1 of 6”, so you can see whether the same failure really looks the same.
- The arrow on the group’s row opens its runs in place in the list. Every run still waiting has a checkbox for selecting it.
- Show N runs switches to the ungrouped list, filtered to this group with a failure group chip.
Dismiss
Section titled “Dismiss”Dismiss when the runs do not need redoing, for example because they came from bad test data. It always asks for a reason, so whoever sees it later knows what was decided. Dismissed runs stay failed, and their reason shows on the run or group.
| Dismiss | Where | What happens |
|---|---|---|
| One run | Dismiss in the run’s header | The run cannot be resumed. The rest of its group stays as it is. |
| A selection | Tick runs, then Dismiss in the bar above | The same, for each. If every run in the group is now dismissed, it reads as Dismissed. |
| A whole group | Dismiss on the group | The group is dismissed. A new failure with the same cause reopens it. |
Only runs still waiting can be dismissed. Resumes already queued when a group is dismissed finish, without changing the group’s status.
Notifications
Section titled “Notifications”Failure notices follow groups, not runs, so a burst of failures sends one notice:
- One when a group opens: “Runs are failing.”
- One when it reopens: “Runs are failing again.”
Each arrives by email and in the app’s notifications, with a link to the group. It names the automation, the block and the cause. For a failure the block itself describes, that is the block’s message. Otherwise it is only the short label, such as “Network error”, because a notice leaves the product.
They go to the person who created the automation, or to the recipients set for it, and only to people who are members of the workspace now. Someone removed from the workspace stops receiving them. Draft runs send none.
- Recover failed runs: test a fix, then resume.
- Runs
- Debug a failed run