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:

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

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.

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.