# Fail-Fast vs Continue-on-Error: Controlling How CI Stops

> Fail-fast stops the pipeline at the first failure; continue-on-error lets it press on. Learn what each does, where they apply, and how to choose.

Source: https://latchkey.dev/learn/ci-cd-concepts/fail-fast-vs-continue-on-error  
Updated: 2026-06-25

Fail-fast stops the moment something fails, to save time. Continue-on-error pushes through a failure to gather more information. They answer opposite questions - and apply at different levels.

These two settings shape how a pipeline reacts to failure: bail early for speed, or keep going for completeness. They operate at different scopes, and mixing them up leads to either wasted minutes or hidden failures.

## Fail-fast (matrix/strategy level)

Fail-fast cancels the remaining parallel jobs as soon as one fails. It saves minutes when any failure means the whole change is bad. The downside: you only learn about the first failing combination, not whether the bug is specific to one OS or version. Disable it when you want the full pass/fail grid.

## Continue-on-error (step/job level)

Continue-on-error marks a step or job so its failure does not fail the run - the pipeline keeps going and reports overall success. It is for non-critical or informational steps (an optional linter, an experimental matrix leg) where you want the result recorded but not gating.

```Non-gating step
- run: ./optional-linter.sh
  continue-on-error: true
```

## They are not opposites of each other

A common confusion: fail-fast governs whether *sibling jobs* get cancelled on a failure; continue-on-error governs whether a *specific step/job’s* failure counts against the run. You can disable fail-fast (run all combinations) and still have some steps gate while others do not.

## Choosing

- Use fail-fast when any failure invalidates the whole change (fast feedback).
- Disable fail-fast when you need to see every combination’s result.
- Use continue-on-error for genuinely optional, informational steps only.
- Never use continue-on-error to paper over a step that should actually gate.

## FAQ

### What is Fail-Fast vs Continue-on-Error: controlling how CI stops?

These two settings shape how a pipeline reacts to failure: bail early for speed, or keep going for completeness. They operate at different scopes, and mixing them up leads to either wasted minutes or hidden failures.

### Fail-fast (matrix/strategy level)?

Fail-fast cancels the remaining parallel jobs as soon as one fails. It saves minutes when any failure means the whole change is bad. The downside: you only learn about the first failing combination, not whether the bug is specific to one OS or version. Disable it when you want the full pass/fail grid.

### Continue-on-error (step/job level)?

Continue-on-error marks a step or job so its failure does not fail the run - the pipeline keeps going and reports overall success. It is for non-critical or informational steps (an optional linter, an experimental matrix leg) where you want the result recorded but not gating.

### They are not opposites of each other?

A common confusion: fail-fast governs whether *sibling jobs* get cancelled on a failure; continue-on-error governs whether a *specific step/job’s* failure counts against the run. You can disable fail-fast (run all combinations) and still have some steps gate while others do not.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt