Execução presa em running no n8n: por que acontece e como achar

O sintoma é sempre o mesmo: você abre a lista de execuções do n8n e encontra uma execução com a bolinha girando, iniciada há dez horas. Não tem erro, não tem log final, não tem nada. Ela simplesmente nunca terminou.

Isso quase nunca é um fluxo lento. Na esmagadora maioria das vezes, aquela execução já morreu — o que sobrou é uma linha no banco que ninguém voltou para corrigir.

Por que a linha fica presa

Uma execução do n8n começa com um registro gravado como running, e o mesmo processo que roda o fluxo é quem depois volta e escreve o resultado — success, error, e a hora em que parou. Se esse processo desaparecer no meio, a segunda escrita nunca acontece. O banco fica com a versão de dez horas atrás, que dizia "estou rodando".

Três coisas fazem o processo desaparecer, nesta ordem de frequência:

1. O contêiner foi morto por falta de memória

É a causa número um, e a mais silenciosa. Um fluxo que carrega uma resposta grande de API, faz um split em milhares de itens ou monta um binário na memória estoura o limite do contêiner, e o kernel mata o processo inteiro — não o fluxo, o processo. Nenhum log do n8n registra isso, porque o n8n não estava mais lá para registrar.

Onde olhar: docker inspect --format='{{.State.OOMKilled}}' <contêiner> depois de um reinício, ou a aba de eventos do seu provedor. Um OOMKilled: true junto de uma execução presa fecha o caso.

2. Deploy, reinício ou troca de versão no meio de uma execução

Toda vez que a plataforma reinicia o serviço — deploy novo, mudança de variável de ambiente, manutenção do provedor — o que estava rodando naquele segundo morre no meio. Em fluxo curto isso quase nunca pega; em fluxo de importação que roda por minutos, pega com frequência incômoda.

3. Modo fila: o worker caiu, a fila não soube

Em queue mode, quem executa é um worker separado. Se ele morre sem devolver o trabalho, a execução fica órfã entre o Redis e o banco. Versões recentes do n8n tentam reconciliar isso no arranque, marcando as sobreviventes como crashed; a reconciliação funciona bem no processo principal e é menos confiável quando o que caiu foi um worker.

Como encontrar as presas

Pela API pública, o filtro de status não oferece running, então o caminho é listar e olhar duas coisas: stoppedAt vazio e startedAt antigo.

curl -s -H "X-N8N-API-KEY: $CHAVE" \
  "https://n8n.suaempresa.com/api/v1/executions?limit=250" \
| jq '[.data[]
      | select(.stoppedAt == null and .waitTill == null)
      | {id, workflowId, startedAt, status}]'

Se você tem acesso ao Postgres do n8n, a consulta é mais direta e pega o histórico inteiro, não só a última página:

select id, "workflowId", "startedAt", status
from execution_entity
where "stoppedAt" is null
  and "waitTill" is null
  and "startedAt" < now() - interval '2 hours'
order by "startedAt";

O corte de duas horas é o que separa "está rodando agora" de "morreu e ninguém percebeu". Ajuste para a execução mais longa que seus fluxos têm de verdade — se o seu maior fluxo leva quarenta minutos, duas horas é folga suficiente.

Por que isso é pior do que parece

Execução presa não é só uma linha feia na lista. Ela custa três coisas:

• Vaga de concorrência. Se você limitou execuções simultâneas (N8N_CONCURRENCY_PRODUCTION_LIMIT), cada presa ocupa uma vaga para sempre. Com o limite em 5 e quatro presas, o fluxo que importa disputa uma vaga só — e você vai investigar "lentidão" por dias.
• A verdade sobre o fluxo. Enquanto ela existe, aquele fluxo parece ter rodado. Nenhum alerta de "parou de rodar" dispara, porque tecnicamente tem execução aberta.
• O trabalho que não foi feito. A execução morreu no meio. Metade dos pedidos foi sincronizada, metade não — e não existe registro de onde parou.

O que fazer

1. Dê um teto de tempo aos fluxos. Em cada workflow, Settings → Timeout. Sem isso, o padrão é não ter limite, e "sem limite" significa que a única coisa que encerra a execução é o processo morrer.
2. Suba a memória do contêiner e meça. Se o OOM aparece, não é o n8n que está com defeito — é o fluxo carregando mais na memória do que cabe. Paginar a origem resolve melhor que dobrar a RAM.
3. Corte o item grande antes que ele entre. Um split em lotes menores muda o pico de memória mais do que qualquer ajuste de infraestrutura.
4. Olhe a lista de presas toda semana. É a checagem mais barata que existe e a que mais dá retorno, porque cada presa é sempre o rastro de um trabalho que ficou pela metade.

Se você opera n8n para clientes

O problema muda de tamanho quando as instâncias não são suas. Ninguém abre cinco painéis toda manhã para conferir stoppedAt — e é justamente por isso que a execução presa costuma ser descoberta pelo cliente, semanas depois, quando ele pergunta por que metade dos pedidos não chegou.