> ## Documentation Index > Fetch the complete documentation index at: https://docs.worksong.ai/llms.txt > Use this file to discover all available pages before exploring further. # Automation run history and automatic turn-off > What each automation records when it runs, and how Work turns off an automation whose rule keeps failing. 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](https://docs.worksong.ai/work/people-and-permissions.md#gates) 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.