Por que a sua automação no n8n parou de rodar

O padrão se repete: o workflow foi montado, testado no editor, funcionou. Duas semanas depois alguém percebe que nada foi publicado desde o dia 12.

Quase sempre é um destes cinco.

1. Falta de memória na VPS

O mais comum, e o menos investigado. n8n roda em Node e cada execução ativa carrega o workflow inteiro em memória. Vários workflows disputando 2 GB numa VPS que também hospeda o site termina com o oom-killer matando processos.

E o que ele mata primeiro raramente é o n8n: costuma ser o MySQL, porque é o processo mais gordo. Aí o sintoma que você vê é “o site caiu”, e ninguém liga uma coisa à outra.

# tem registro de OOM?
sudo dmesg | grep -i "killed process"

# quanto sobra de verdade
free -h

Se o available vive abaixo de 15% do total, o problema é esse, não o workflow.

2. Credencial expirada

Token de API de rede social expira. Refresh token de OAuth expira. Senha de aplicativo é revogada quando alguém troca a senha principal.

O sintoma é característico: o workflow roda, chega no nó de publicação, recebe 401 e para. Se não houver caminho de erro configurado, isso acontece em absoluto silêncio.

Vale anotar em calendário a validade de cada credencial. É burocrático e evita metade das paradas.

3. Webhook que mudou de endereço

Se o n8n está atrás de um túnel ou de um domínio que mudou, todo webhook cadastrado em serviço externo continua apontando para o endereço antigo. O serviço externo tenta, recebe erro, e depois de algumas tentativas para de tentar.

O teste é direto:

curl -i -X POST https://seu-n8n/webhook/seu-path

Se não responder 200, o problema não está no workflow, está no caminho até ele.

4. Rate limit silencioso

APIs de rede social limitam requisições por janela de tempo. Um workflow que publica em quatro redes para trinta clientes dispara cento e vinte chamadas em minutos.

A resposta ao estouro nem sempre é um erro claro. Às vezes é 200 com o conteúdo descartado. O workflow marca sucesso e nada foi publicado.

A correção é espaçar: nós de espera entre publicações, e escalonamento por cliente em vez de rajada.

5. Fila travada por execução pendurada

Uma execução que não termina, porque esperava resposta de um serviço que nunca respondeu, pode segurar a fila. As seguintes entram como waiting e o workflow parece ativo enquanto não faz nada.

Vale checar na aba de execuções se existe algo em andamento há horas, e definir timeout em todo nó que chama serviço externo. Nó HTTP sem timeout é uma armadilha esperando o dia em que a outra ponta ficar lenta.

O que fazer antes de tudo isso

Duas medidas evitam a maior parte dos sustos:

Caminho de erro que avisa fora do n8n. Todo workflow crítico precisa de um ramo de erro que mande mensagem para onde você realmente olha. Log interno não avisa ninguém.

Um monitor externo. Um serviço simples que espera um “estou vivo” a cada intervalo e reclama quando não chega. Se o n8n cair inteiro, ele é o único que vai te contar.

Automação sem monitoramento não é automação. É uma aposta com prazo indeterminado.

Onde o n8n encaixa bem

Nada disso é argumento contra a ferramenta, que é excelente no que faz: conectar serviços, mover dados, disparar ações.

O que ele não é: o lugar onde a decisão editorial acontece. n8n distribuindo o que já foi produzido e aprovado funciona muito bem. n8n tentando ser o cérebro que decide o que publicar é onde a fragilidade aparece, porque aí cada nova regra vira mais um nó, e um dia ninguém entende mais o desenho.