Preciso começar a monitorar os fluxos de trabalho melhor.
Como vocês estão fazendo isso?
@patriciaLee a resposta nativa que a maioria das pessoas perde é o Error Workflow, configure um globalmente em Settings e ele dispara em qualquer execução falhada para que você possa enviar o erro para slack/email/onde quiser sem fazer polling de nada. para navegação/auditoria há a visualização Executions com filtros de status. e se você estiver com self-hosted, configure N8N_METRICS=true para expor um endpoint /metrics do prometheus que você pode coletar no grafana para dashboards e alerting. error workflow + metrics cobre a maioria das configurações de produção.
Existem duas categorias que avalio. A primeira categoria é a saúde da execução. Quero saber se a execução começou, terminou ou encontrou um erro. A outra categoria é o resultado comercial. Tenho que determinar se a execução fez o que deveria fazer. Esta categoria é mais difícil de avaliar. Por exemplo, se uma execução fez um filtro pular todos os registros, a execução seria bem-sucedida mas completamente inútil.
Se um fluxo de trabalho é importante o suficiente, vou registrar mais detalhes, incluindo o número de registros processados, o status final do fluxo de trabalho, o motivo da falha do fluxo de trabalho, o proprietário do fluxo de trabalho e a próxima etapa proposta.
Além de erros, monitoro alguns outros sintomas. Por exemplo, se fluxos de trabalho não foram concluídos com sucesso, se o número de registros processados cai para 0, ou se há um número crescente de tentativas de repetição, emitirei um alerta. Sempre me esforço para tornar os alertas acionáveis.
@patriciaLee achamm cobriu o essencial (Error Workflow + Executions view + Prometheus/Grafana) — essa é a base certa. Duas coisas que eu adicionaria para capturar o que aqueles perdem:
-
Torne o Error Workflow realmente acionável. Um alerta nú “um workflow falhou” não é suficiente. No seu Error Workflow global, envie uma mensagem que inclua o nome do workflow, a URL da execução, o nó que falhou e a mensagem de erro — isso transforma uma caçada de 20 minutos em um clique para a execução quebrada. Também configure EXECUTIONS_DATA_SAVE_ON_ERROR=all (e remova execuções bem-sucedidas com as configurações de data-prune) para manter execuções falhadas para debug sem inchar o DB.
-
Fique atento a falhas SILENCIOSAS — o ponto cego real. Error Workflow + métricas só disparam quando um workflow roda e lança erro. Eles NÃO capturam um workflow que silenciosamente para de rodar — um trigger que morre, um webhook que se desregistra, um cron que quieto para. Essa é a falha que realmente dói, porque você fica sabendo dias depois do cliente. O fix é um dead-man’s switch: um Schedule trigger que faz ping em um serviço de heartbeat (Healthchecks, Better Stack, ou self-hosted Uptime Kuma) a cada poucos minutos. Se o ping parar de chegar, ele o alerta — então você detecta “parou de rodar completamente,” não só “rodou e deu erro.”
Se você for self-hosted, eu também colocaria um monitor básico de uptime na instância/container n8n em si, para você saber se a coisa toda está down vs. apenas um workflow.
A configuração em camadas que eu rodaria: Error Workflow com contexto rico para falhas em tempo de execução → Prometheus/Grafana para saúde agregada → um heartbeat/dead-man’s switch para paradas silenciosas → um monitor de uptime na instância. A maioria das pessoas configura os dois primeiros; o heartbeat é aquele que quase todos esquecem até morder.
Bom ponto do @ShawnWilliams sobre a distinção entre integridade de execução vs. resultado empresarial. Um exemplo da segunda categoria que talvez ajude: construí um fluxo de trabalho diário que não monitora erros, mas oportunidades de conteúdo, ele varre posts de fóruns e avalia via LLM se são relevantes para mim, então envia um resumo por email.
O ponto é: “Monitoramento” não precisa significar apenas erros. Você pode usar o mesmo mecanismo de fluxo de erro para reconhecer também gatilhos positivos, sejam novos leads, conteúdos, ou justamente perguntas abertas que você pode responder. A base técnica (setup do achamms) permanece igual, apenas a condição que dispara o alerta muda de “erro ocorreu” para “evento interessante detectado”.
@patriciaLee e outros cobriram as peças principais (Error Workflow, Executions view, Prometheus/Grafana, e a distinção entre execution health vs. business outcomes). Eu adicionaria uma camada a mais que me causou problemas em produção: silent failures.
Error Workflows e métricas só ajudam quando algo realmente é executado e lança um erro. Eles não capturam um trigger que para de dispara, uma webhook subscription que expira silenciosamente (Gmail watches são um exemplo clássico), ou um cron job que nunca roda. Nada é executado, então nada é observado. Na minha experiência, essas são geralmente as falhas mais dolorosas porque você as descobre por um cliente ao invés do monitoramento.
A abordagem em que cheguei é um dead-man’s switch: um workflow agendado faz ping em um serviço de heartbeat (Healthchecks.io, Better Stack, ou Uptime Kuma auto-hospedado). Se o heartbeat parar de chegar, isso é o alerta. Complementa Error Workflows detectando “parou de rodar completamente”, não apenas “rodou e falhou”.
Também gosto do ponto de Shawn sobre business outcomes. Para workflows importantes, rastreio coisas como registros processados, retry counts, volumes mínimos esperados e propriedade. Um workflow que processa com sucesso zero registros pode estar tecnicamente saudável mas operacionalmente inútil, então essas métricas merecem alertas também.
O modelo em camadas que funcionou bem para mim é:
- Error Workflow → contexto rico (workflow, node, execution URL, detalhes do erro)
- Prometheus/Grafana → métricas agregadas e tendências
- Business metrics → registros processados, retries, resultados esperados
- Heartbeat/dead-man’s switch → silent failures
- Uptime monitoring → instance/container health
A maioria das pessoas implementa as duas primeiras camadas. As camadas de heartbeat e business outcomes são as que tendem a salvá-lo de surpresas desagradáveis depois.
A divisão de Shawn é a que eu usaria: saúde da execução vs resultado comercial.
Para fluxos de cliente, eu adicionaria um pequeno recibo de execução ao alerta: janela esperada, registros tocados, conta/credencial utilizada, ação a jusante tentada, ID final do registro/mensagem e quem é responsável pela próxima etapa. A execução verde é menos útil do que a prova do que mudou.
Esta thread já cobre bem a divisão importante: saúde da execução versus se o resultado realmente aconteceu, além da ideia do heartbeat para a execução que nunca dispara, então vou apenas adicionar a falha que ainda passa despercebida por tudo isso. Mesmo com uma verificação de contagem de registros e um mecanismo de proteção em funcionamento, o caso que pega as pessoas é a execução que se completa, processa seu número usual de linhas, não lança nada e ainda está incorreta, porque uma credencial expirou silenciosamente ou uma fonte ficou obsoleta e a API devolveu uma resposta válida mas vazia ou de espaço reservado. A contagem parece normal, o status fica verde, nada gera erro, então nenhuma das camadas acima sinaliza.
A razão pela qual um Error Trigger padrão fica cego para isso é que não houve erro. O token não falhou ruidosamente, ele retornou um 200 limpo sem nada útil dentro, e o workflow mapeou felizmente isso para frente. Um alerta de contagem de registros também perde, porque a contagem pode estar normal enquanto o conteúdo está obsoleto ou em branco.
O que pega isso sem muito esforço é verificar o conteúdo, não apenas a presença. Depois de qualquer chamada sensível à autenticação, faça uma asserção em um campo que só aparece quando a chamada realmente funcionou, em vez de apenas verificar se a resposta não está vazia, e adicione uma verificação de atualização: o registro mais novo é realmente recente ou estou vendo dados de ontem sendo devolvidos para mim. Para o ângulo de credencial especificamente, ajuda tratar um resultado vazio inesperado de uma fonte normalmente ativa como uma condição de falha em vez de um sucesso silencioso.
A mentalidade que une toda a thread: uma execução verde com uma contagem de linhas normal ainda não é prova de que os dados são reais, apenas que algo foi devolvido. A verificação que vale a pena adicionar é se o resultado é fresco e correto, não apenas presente. O que vocês fazem sobre o caso obsoleto-mas-verde, ou ainda não foram afetados por isso?
Este tópico cobre bem as camadas principais: fluxo de erro com contexto, Prometheus/Grafana, heartbeat para falhas silenciosas, e o caso verde-mas-desatualizado que alguém levantou. Uma lacuna que eu adicionaria, especialmente se você não estiver rodando n8n em isolamento:
Tudo mencionado até agora é nativo do n8n. Error Workflow, N8N_METRICS, a visualização de Executions. É a decisão certa se n8n é sua única superfície de automação. Mas muitos times não são puramente n8n. Eles têm cenários do Make, alguns Zapiers, um cron job, talvez um script ou dois, todos fazendo trabalho real em produção. Cada um tem seu próprio dashboard, então “está tudo saudável” significa checar três ou quatro lugares diferentes, e o padrão de heartbeat que as pessoas descreveram aqui tem que ser reconstruído separadamente para cada ferramenta.
O padrão que funcionou para mim: trate “rodou, sucedeu, falhou” como um evento simples que você dispara de qualquer lugar onde a automação vive. Uma chamada HTTP dos caminhos de sucesso e erro do n8n, a mesma coisa de um webhook do Make ou de um webhook do Zapier ou um try/except em um script, todos chegando em um lugar que não se importa qual ferramenta enviou. A mesma ideia de heartbeat acima, só que não presa a uma plataforma.
Aviso já que devo ser direto: eu construí uma ferramenta exatamente para isso (FlowPulse) depois de bater nesse mesmo problema de “quatro dashboards, nenhuma visualização única” eu mesmo. Não estou tentando fazer um pitch no meio de uma boa discussão, só sinalizando que existe caso a parte multi-plataforma seja útil para alguém. Fico feliz em conversar sobre a versão DIY também se for mais seu estilo.