Skip to main content
Every automation keeps its own history. If its rule is broken, Work turns it off after a few failed runs and tells its owner once.

​
Run history

Each time an automation runs, Work records the run: its result, the item that started it, how long it took, and one row for every action it reached. A failed run also keeps the error and a failure kind:
  • config: the rule itself is broken. For example, the group it moves items to was deleted, or the column it writes to is gone.
  • error: anything else, such as a conflict or an outage on the other side.
Read one automation’s runs with GET /v1/automations/{id}/runs (newest first, up to 200, tests included unless you pass includeTests=false). You need Manage on the board. The answer also says whether the automation is on and, if Work turned it off, when, after how many failures and why. The board’s list, GET /v1/boards/{boardId}/automation-runs, shows the same runs with the new keys durationMs, failureKind and error. Agents use the MCP tool boardy_get_automation_runs with an automationId to get the same view. In the app, open an automation and tap Run history.

​
When Work turns an automation off

An automation is turned off after 5 failed runs in a row, when every one of those failures is a config failure. These do not count, and none of them ends the count either:
  • A run that was denied, held for an approval or stopped by a limit. That is governance doing its job, not a broken rule.
  • A run that did nothing (skipped), a run still going, and a test run.
  • A run that failed with an error kind. It does not prove the rule is broken, and it does not prove it is fixed.
A successful run ends the count. Editing the automation, or turning it back on, starts a new count. Turning it off is one change: the automation is switched off, the change is written to the audit log, and its owner gets one notification. The owner is the person who created the automation. If that person is no longer active, it is the board’s owner, then the member the automation runs as, then the workspace owner. The notification is a normal row in the inbox. It says the automation was turned off, names the board, and shows the last error. Tapping it opens the board’s automations. A member who cannot read the board only sees “An automation was turned off” and a link to Work.

​
Turn it back on

Fix the rule first (for example, point the action at a group that exists), then turn the automation on. In the app, the editor of a turned-off automation shows the reason and a Turn back on button. Through the API, use PATCH /v1/automations/{id}/enabled with { "enabled": true }. The automation starts with a fresh count. If it breaks again, it is turned off again, with a new notification.

​
Change the limit

The default is 5. A workspace operator can set Automation:DisableAfterConfigFailures (1 to 100). A value that is missing, zero or negative means 5. Source: worksong-ai/worksong:services/work/src/Boardy.Workers/AutomationHealthMonitor.cs@c0eb87d, worksong-ai/worksong:services/work/src/Boardy.Automation/Application/AutomationHealth.cs@c0eb87d, worksong-ai/worksong:services/work/src/Boardy.Workers/AutomationRunRecorder.cs@c0eb87d. Docs version: Worksong 2.0 with Work 1.2.