Os que enviam faturas, direcionam leads ou enviam mensagens aos clientes. Eles podem parar sem gerar nenhum erro enquanto o dashboard continua parecendo normal.
Quem percebeu primeiro quando isso aconteceu pela última vez com você, você ou um cliente?
No meu caso, tento não deixar o cliente ser o primeiro a notar 
Eu uso um fluxo de trabalho centralizado de tratamento de erros no n8n que captura fluxos de trabalho com falha, classifica a severidade e envia um alerta com os detalhes do fluxo de trabalho e da execução.
Mas as falhas silenciosas são um problema mais interessante.
Um fluxo de trabalho pode ser executado com sucesso enquanto o resultado de negócio real nunca acontece.
Monitorar isso requer uma abordagem diferente de apenas capturar erros de execução.
seus clientes pagam separadamente por esse alerta, ou é parte do preço da compilação?
Ninguém notou, e essa é a resposta que tenho. Eu não tinha clientes, então não havia ninguém para notar, e encontrei ambos por acaso enquanto fazia outra coisa. Deletei uma tarefa agendada, fiz o deploy, e a tarefa deletada ainda estava na fila de execução, o que é como descobri que o agendador estava com duas semanas de atraso. O outro eu encontrei porque tirei uma captura de tela para mostrar a alguém e vi uma linha de ferramentas que não dizia nada onde uma chamada recusada deveria estar. Nenhum foi detectado por uma verificação que eu tinha escrito propositalmente. Quando era um fluxo de trabalho do cliente, você os informou que tinha parado, ou corrigiu silenciosamente e não disse nada?
Atualmente, trato o tratamento básico de erros como parte da compilação.
Se entregar um fluxo de trabalho de produção, eu realmente não o considero completo sem tratamento de erros adequado e alertas.
Monitoramento contínuo e suporte é uma história diferente.
Eu trataria isso como parte de um pacote de hospedagem/suporte recorrente, em vez do preço inicial de compilação.
Para os silenciosos nos fluxos de trabalho dos seus clientes, o que você usa para detectá-los hoje, e isso custa algo para você?
Ninguém notou no meu caso também, e só descobri porque fui procurar.
Apontei um monitor somente leitura para minha própria instância algumas semanas atrás e encontrei 28 falhas consecutivas em um fluxo de trabalho, ao longo de cerca de 24 horas, três dias antes de eu olhar para isso. Elas estavam em minha lista de execução marcadas corretamente como erros o tempo todo. O n8n tinha feito seu trabalho perfeitamente. A causa não estava no n8n — tínhamos migrado o aplicativo que esses fluxos de trabalho chamam de EC2 para Vercel, e a lista de verificação tinha uma linha para DNS e nada para “a coisa que chama isso”.
@Aghassi para sua pergunta, porque é a desconfortável: eu contei. Não imediatamente — primeiro corrigi, depois disse o que tinha acontecido e por quanto tempo tinha estado quebrado. O que não consegui responder foi “como saberíamos na próxima vez”, e essa foi a parte que realmente custou minha confiança, não a indisponibilidade em si.
@StefanGwiggner a divisão que você descreve é aquela em que também cheguei, tratamento de erros dentro do build e monitoramento na linha recorrente. A parte que achei genuinamente difícil é que uma linha recorrente para monitoramento tem que ser renovada pela força de nada ter acontecido. Quando funciona, não há nenhum incidente para apontar, então o cliente está pagando por uma ausência. A única resposta que encontrei é enviar algo regular que diga o que foi verificado e o que encontrou, mesmo quando a resposta honesta é nada — caso contrário, o silêncio parece que o serviço parou em vez do problema ter parado.
O monitor somente leitura que você apontou para sua instância, é uma ferramenta que você paga ou algo que você construiu por conta própria?
Na verdade, essa é a parte em que ainda estou trabalhando.
Meu fluxo de erro central lida com falhas de execução técnica, mas uma verdadeira falha silenciosa é diferente porque o n8n pode relatar uma execução bem-sucedida enquanto o resultado de negócio esperado nunca aconteceu.
Para esses casos, acho que o monitoramento precisa estar vinculado ao resultado esperado, e não apenas ao status do fluxo de trabalho.
Por exemplo:
A fatura realmente foi criada
O lead chegou ao CRM
A mensagem do cliente foi realmente enviada
…
Ainda não tenho uma solução universal para isso porque a verificação de integridade depende muito do que o fluxo de trabalho deveria realizar.
Algum de seus clientes paga por esse pacote mensal de hospedagem/suporte hoje em dia, e quanto aproximadamente por mês?
A parte por fluxo de trabalho é real, a verificação precisa saber o que esse fluxo de trabalho era para realizar. O que se generaliza é a forma da verificação, e há duas delas que valem a pena manter separadas.
A primeira detecta ausência: a fatura foi criada, o lead chegou ao CRM. Você consulta o sistema de destino em um cronograma, independentemente do log de execução, e compara o que chegou com o que a fonte ofereceu. Essa é a versão bilateral que Aghassi descreve, e é o que evita que um dia calmo pareça um quebrado.
A segunda detecta o caso que a primeira não consegue: a fatura foi criada, o número correto de linhas se moveu, e os valores nelas estão errados. Um mapeamento se desviou, um modelo foi trocado, um campo upstream mudou de significado mas não de forma. Para isso, escolha um ou dois casos por fluxo de trabalho crítico onde você sabe a saída correta com antecedência, uma fatura de teste que você pode recomputar manualmente, uma consulta conhecida, e execute exatamente esse caso através do fluxo de trabalho de produção ao vivo em um cronograma, separado do tráfego real. Você não está verificando se ele foi executado ou quanto se moveu, você está verificando se a resposta ainda corresponde àquela que você anotou beforehand.
O segundo também ajuda com o problema de renovação que Loordhu levantou. Uma nota mensal que diz que sua fatura de teste voltou correta 30 vezes em 30 carrega um número que poderia ter estado errado, então lê como uma verificação que foi executada, não como silêncio.
Ainda não.
No momento, estou fazendo a transição de projetos para mim mesmo, amigos e família para trabalhar com clientes externos, então ainda não tenho um preço real de suporte mensal respaldado por clientes que pagam.
Comecei há apenas um mês.
O modelo que estou planejando é uma taxa de implementação única mais um pacote recorrente de hospedagem, monitoramento e suporte.
Prefiro não lançar um número antes de validá-lo com clientes reais 
A camada em que todos neste tópico estão contando para detectar as falhas ruidosas pode falhar silenciosamente ela mesma. Entrei no código-fonte do n8n para verificar exatamente como, e depois observei cada caso acontecer na minha própria instância, então os números abaixo vêm da minha própria lista de execução e não da teoria.
Três mecanismos, nenhum dos quais aparece em qualquer lugar no editor.
Um workflow de erro pode estar inativo enquanto ainda está definido como o workflow de erro em todos os workflows que apontam para ele. O n8n mantém a configuração, o menu suspenso ainda mostra o nome, e quando uma falha acontece ele escreve uma linha no log do servidor, Calling Error Workflow for "X". Workflow "Y" is not active and cannot be executed. Essa linha é toda a notificação. A mesma forma se o workflow de erro está ativo mas não tem nenhum nó Error Trigger nele: uma linha de log, nenhum alerta.
As execuções travadas são o pior caso, e @Daniel_Goh tem uma thread aberta exatamente sobre essa situação agora. Quando o processo morre durante a execução não há dados de execução e nenhum erro é lançado, então nada é acionado no momento da falha. A execução é marcada como travada na próxima inicialização, e o workflow de erro é executado então. Não quando falhou. Na próxima inicialização. Se o container fica inativo por seis horas, o alerta chega seis horas atrasado, e se nunca volta de forma limpa não há alerta nenhum.
Então sobre o ponto de @StefanGwiggner de que um workflow de produção não está completo sem o tratamento de erros adequado, eu agora inverteria: o tratamento de erros é a parte em que confio menos, porque é a única parte da pilha cujo modo de falha é silêncio por design. Tudo que monitora uma instância n8n tem que ficar fora dela e lê-la de volta pela API. Um monitor vivendo dentro da instância fica na zona de explosão da coisa que supostamente deveria relatar. Quando desliguei meu próprio workflow de erro como teste, o rastreamento nativo foi aquela uma linha de log. O monitor externo sinalizou em cinco minutos.
@Loordhu_Jeyakumar sobre o problema de renovação, @Adam13y a resposta correta é aquela e posso colocar números nela, porque é exatamente como a minha relata. Nos últimos cinco dias registrou 1.409 verificações de heartbeat contra minha instância e abriu seis alertas. Dois deles foram não planejados: no domingo minha instância ficou silenciosa duas vezes, cada uma detectada por um heartbeat perdido, e ambos os alertas se fecharam sozinhos quando os heartbeats foram retomados, um após 4 minutos e outro após 29. A causa acabou sendo meu próprio laptop entrando em modo de suspensão, o que é principalmente uma lição sobre onde não executar n8n. Mas essa é a linha mensal que um cliente pode renovar. Não “sem incidentes este mês”, mas 1.409 verificações, dois problemas, ambos detectados, ambos fechados, aqui estão os timestamps.
Para responder sua pergunta diretamente, Vladislav: eu construí em vez de comprar. O que encontrei quando olhei quer um nó instalado dentro de cada workflow que você quer monitorar, o que coloca o monitor novamente na zona de explosão, e significa que os workflows que você esqueceu de instrumentar são exatamente aqueles sobre os quais você não ouve nada.
@StefanGwiggner uma pergunta de volta sobre o pacote recorrente que você está montando, porque a resposta decide como a camada de monitoramento tem que funcionar: você está planejando hospedar as instâncias dos seus clientes você mesmo, ou monitorar instâncias que os clientes possuem? Monitorar sua própria frota e monitorar a de outro acabam sendo problemas diferentes, e estou curioso em qual lado você está construindo.
Obrigado, o fluxo de erro inativo que ainda aparece no dropdown é bem chato. Além de você, mais alguém está rodando seu monitor, e pagando por ele?
Não. Apenas eu por enquanto, ele está monitorando minha própria instância há cerca de uma semana. Essa é a verdadeira razão pela qual estou em threads como esta, estou tentando descobrir se alguém pagaria por isso e por quê, antes de construir mais alguma coisa.
Por curiosidade, você perguntou a todos neste thread quem paga por quê. Você também está construindo algo neste espaço?
@Vladislav_Vladislav construí isso eu mesmo. É pequeno: lê a API do n8n de fora da instância, somente leitura, e fica observando execuções que falharam, execuções que deveriam ter acontecido e não aconteceram, e a própria instância ficando silenciosa. E para responder a pergunta que você fez ao Benzy antes de me fazer: não, ninguém mais está executando isso ainda, e ninguém está pagando por isso. No mesmo lugar que ele descreveu. Se você gerencia instâncias para clientes e quer ver o que isso diz sobre uma delas, fico feliz em apontá-lo para ela, mande-me uma DM.
@Adam13y @Benzy sobre o problema de renovação, o caso de resposta conhecida é a parte que não tinha. Tudo que envio hoje é do tipo ausência honesta. Meus números reais desde 12 de setembro: 28.308 verificações de saúde contra minha própria instância, 5 falhadas, e um alerta de erro, a mesma falha de sub-nó 36 vezes entre 11 e 18 de setembro, que foi real e foi meu para corrigir. Esses são números que poderiam ter estado errados, mas nenhum deles diz que uma única fatura saiu correta.
Uma coisa que vai contra minha própria configuração, e se encaixa no ponto de Benzy sobre onde o monitor fica: em 25 de setembro ele levantou um “instance down” de 50 segundos, e no mesmo minuto falhou em alcançar seu próprio provedor de e-mail. Então a história mais provável é que meu monitor perdeu sua rede, não que o n8n desceu. Fora do raio de impacto é correto, mas fora significa que você herda um segundo raio de impacto da sua conta, e o relatório tem que dizer qual lado piscou.
@Benzy Desculpa pela resposta atrasada, estive offline por alguns dias.
No momento estou inclinado a hospedar e gerenciar as instâncias dos clientes nós mesmos. Provavelmente uma instância de produção por cliente, com monitoramento, backups e tratamento de erros incluídos no serviço recorrente.
Para clientes que já têm sua própria configuração de n8n eu ainda ofereceria monitoramento, mas como você disse, isso se torna um problema diferente. Se a gente hospeda, conseguimos monitorar praticamente toda a pilha. Na infraestrutura deles, obviamente dependemos do acesso que eles nos dão.
Seu ponto de “observador fora do raio de explosão” realmente me marcou. Já uso tratamento de erros interno, mas essa discussão me convenceu de que confiar apenas nisso provavelmente não é suficiente.
Ainda estou descobrindo exatamente como será o pacote recorrente, então essa thread foi realmente útil para mim. 
E obrigado por perguntar!
Faz sentido, e hospedá-los você mesmo é o lado mais fácil de monitorar. Quantas instâncias de cliente você está planejando iniciar? Se ajudar enquanto você monta o pacote, posso apontar meu monitorador para uma delas gratuitamente e você pode ver o que ele teria te dito.
@Benzy sim, estava verificando a mesma coisa. Postei um anúncio de “Procuro Trabalho” aqui oferecendo monitoramento diário de 3 workflows por $150 por mês. Recebeu 65 visualizações e nenhum comprador, e ninguém que perguntei nesta thread conseguiu nomear um cliente que já paga por monitoramento. Então deixei de lado por enquanto.
@Loordhu_Jeyakumar obrigado pela oferta, mas não executo instâncias para clientes, então não há nada para apontar. Se algum de vocês encontrar alguém que pague, eu realmente gostaria de saber exatamente pelo que estão pagando.
Obrigado por compartilhar os números, isso é útil. Vou fazer isso se encontrar um.