# Fail-Fast vs Continue-on-Error: Controlando Como o CI Para

> O fail-fast interrompe o pipeline na primeira falha; o continue-on-error deixa que ele prossiga. Aprenda o que cada um faz, onde se aplicam e como escolher.

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

O fail-fast para no momento em que algo falha, para economizar tempo. O continue-on-error avança apesar de uma falha para reunir mais informações. Eles respondem a perguntas opostas - e se aplicam em níveis diferentes.

Essas duas configurações determinam como um pipeline reage a uma falha: abandonar cedo por velocidade, ou continuar por completude. Elas operam em escopos diferentes, e confundi-las leva a minutos desperdiçados ou a falhas ocultas.

## Fail-fast (nível de matrix/strategy)

O fail-fast cancela os jobs paralelos restantes assim que um falha. Ele economiza minutos quando qualquer falha significa que a mudança inteira está errada. A desvantagem: você só fica sabendo da primeira combinação com falha, não se o bug é específico de um OS ou de uma versão. Desative-o quando quiser a grade completa de pass/fail.

## Continue-on-error (nível de step/job)

O continue-on-error marca um step ou job para que sua falha não faça a execução falhar - o pipeline continua e reporta sucesso geral. Ele serve para steps não críticos ou informativos (um linter opcional, uma perna experimental da matrix) onde você quer o resultado registrado mas não como gate.

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

## Eles não são opostos um do outro

Uma confusão comum: o fail-fast governa se os *jobs irmãos* são cancelados em uma falha; o continue-on-error governa se a falha de um *step/job específico* conta contra a execução. Você pode desativar o fail-fast (rodar todas as combinações) e ainda ter alguns steps servindo de gate enquanto outros não.

## Escolhendo

- Use o fail-fast quando qualquer falha invalida a mudança inteira (feedback rápido).
- Desative o fail-fast quando precisar ver o resultado de cada combinação.
- Use o continue-on-error apenas para steps genuinamente opcionais e informativos.
- Nunca use o continue-on-error para encobrir um step que deveria de fato servir de 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