---
title: "Fix tasks from failures"
description: "How a failed pipeline run or deploy becomes one prioritised fix task in your queue, and how connected agents pick it up."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Fix tasks from failures

When something fails, Overlane opens a fix task for it. You do not have to notice the failure, write it up or rank it.

Overlane runs no fixing agent of its own. It detects the failure, writes the task and puts it in the queue. The agents you have connected, such as Claude Code and Codex, take it from there with `overlane task next`, and Overlane tracks the work like any other task.

## What opens a task

- A pipeline run that fails on `main`. One task is opened per failing job. Runs on other branches and pull requests are the author's to fix and open nothing.
- A deploy that fails to go live. The previous release keeps serving.

## What the task holds

- A title naming what failed and where, the `self-heal` label, and a task in the queue with the same priority.
- The evidence: the failing step and its exit code, the commit, the run or release, and how to read the run's logs: the `overlane ci logs` command for the run, and the API path behind it.
- The rules for the fix, written into the task: find the cause and fix it in the code, never skip, weaken or retry a failing check, never raise a timeout or loosen a published limit such as the page-speed limit, and add a test that fails without the fix.

## One failure, one task

Overlane compares what failed, where, and what it said, ignoring commit ids, run ids, times, counts and durations. The same failure on a later commit updates the open task instead of opening another, and its description shows how many times it has been seen.

If the task is verified and closed and the failure comes back, a new task opens for the new breakage.

## Likely cause

Rules read the failure first: a timeout or rate limit is labelled `cause:infra`, a missing secret or setting `cause:config`, a compile or type error `cause:code`, a failing assertion `cause:test`. Only a failure no rule recognises can go to the decision model, and only when your team has switched on the `failure_cause` use:

```sh
overlane decision settings set failure_cause --enabled on
```

The model sees the redacted failure message only and can pick one of those four or say it is unsure. If it is off, unsure or fails, the task simply has no cause label. The label and the hint line in the description point at where to look; they never change the priority or what the fix may touch.

## Priority

| Failure | Priority |
| --- | --- |
| A production deploy | P0 |
| A pipeline run on `main`, or a non-production deploy | P1 |

A failure seen three times is raised one level, and a task is never lowered by a repeat. The queue then orders tasks as it always does; see [Tasks and priority](/task-priority/).

## Landing the fix

The fix goes through the same review, verify and release path as any change. A fix task is closed by its evidence, the same as every task, never by hand.

Source: https://docs.overlane.app/issues/self-healing/index.mdx