Algo que vejo constantemente em workflows de produção do n8n que confunde as pessoas.
Quando você ativa Continue On Fail em um nó, o n8n marca a execução como sucesso mesmo que aquele nó falhe com um 500, um 401 ou uma resposta vazia. O erro é passado para baixo como dados de saída de erro, o workflow continua rodando, e o status de execução de nível superior fica verde.
Isso significa: seu nó HubSpot falhou, sua linha no CRM nunca foi criada, seu cliente nunca recebeu o email — e o log de execução do n8n mostra sucesso.
Três lugares onde isso causa real dor de cabeça:
-
Nós HTTP Request com Continue On Fail — um 500 de uma API se parece idêntico a um 200 na visualização de execução
-
Nós Code que lançam erros — silenciosamente passados para baixo
-
Qualquer nó em um fluxo com múltiplas etapas onde você “apenas quer que continue funcionando”
A solução é adicionar um nó IF explícito após qualquer nó crítico que use Continue On Fail — verificar a presença de $json.error na saída e rotear para uma branch de alerta.
Alguém mais se deparou com isso em produção? Curioso como as pessoas estão lidando com isso em workflows maiores.
boas adições. a forma de erro inconsistente causa problemas constantemente. tratar tanto $json.error.message quanto $json.error como uma string simples na mesma verificação IF é a decisão certa.
o caso de zero itens é mais complicado do que CoF em alguns aspectos. sem forma de erro, o fluxo simplesmente para, tudo a montante fica verde. eu adiciono verificações explícitas de contagem de itens em nós onde uma saída vazia é uma falha real, não apenas um caso extremo silencioso.
sobre a configuração: um Error Trigger central para falhas óbvias, mas isso deixa os casos de CoF e zero itens sem cobertura. estou desenvolvendo algo especificamente para o padrão verde-mas-quebrado. qual é o lugar mais comum em que zero itens causa problemas para as pessoas em produção?
Encontrei esse problema exato em produção com fluxos de relatórios voltados para clientes. O padrão inline IF-após-CoF funciona, mas tem uma fraqueza estrutural: cada verificação vive dentro do fluxo que ela está verificando. Se o fluxo parar cedo (seu caso de itens zero), ou alguém editar um nó e remover a ramificação de verificação, a validação morre com isso — e tudo antes ainda mostra verde.
No que convergi: mantenha as verificações inline para roteamento, mas mova a validação de saúde PARA FORA do fluxo. Cada fluxo de produção escreve uma linha de metadados de execução (status, contagem de itens, timestamp) em uma planilha de log como seu último passo; um watcher agendado separado lê o log e alerta sobre execuções perdidas, linhas de erro ou saídas com contagem zero. O watcher sobrevive a qualquer coisa que aconteça dentro dos fluxos que ele monitora — incluindo eles não executarem nada, o que nenhuma verificação inline consegue detectar.
Tenho curiosidade em qual escala isso começa a prejudicar as pessoas — quantos fluxos de produção você está executando quando construiu sua disciplina de CoF?
@dima_automation Para zero itens causando problemas em produção - o lugar mais comum que vejo é Google Sheets “Get Rows” com um filtro que não retorna nada (token expirado, planilha renomeada, intervalo errado). O workflow executa corretamente com zero itens, cada nó downstream produz zero itens, e o nó final de envio/escrita simplesmente nunca é executado. Sem erro, log verde, cliente não recebe relatório. Segundo mais comum: paginação de nó HTTP Request que sai mais cedo porque a API muda o schema de resposta e a verificação “tem mais páginas” retorna false. O fix que uso: depois de qualquer nó onde zero output seria uma falha real, adiciono um nó IF verificando {{ $items().length === 0 }} e roteiio isso para um alerta explícito em vez de continuar silenciosamente.
Ambos são manuais clássicos, especialmente o Sheets Get Rows com um filtro que silenciosamente não corresponde a nada, rio abaixo tudo zero, envio final nunca executa, log verde. Essa é a explicação mais clara de todo o problema que já vi.
O nó IF verificando {{ $items().length === 0 }} é o protetor de fluxo correto onde zero é inequivocamente uma falha. Uma coisa que vale a pena destacar: ele captura seu primeiro caso, mas não o segundo. A saída de paginação antecipada retorna um conjunto truncado mas diferente de zero, então length === 0 passa direto, o fluxo recebeu 40 de 200 linhas e cada nó está feliz com dados não vazios. Esse precisa de uma contagem esperada ou de uma verificação de baseline, basicamente se isso está muito abaixo do que essa execução normalmente produz, não apenas zero versus não.
E ambos os padrões ainda assumem que a execução foi acionada. A versão mais perigosa é o fluxo de trabalho agendado que nunca foi acionado, nenhum nó IF executa porque nada executou, nada se lê como zero porque nada foi executado. Esse é o caso que me levou a verificar o resultado de fora da execução, um protetor por nó não pode proteger uma execução que não aconteceu. Sua verificação de zero mais uma baseline de contagem mais uma verificação de liveness de fora cobre a maioria da superfície entre eles.