Alguns workflows não mostram nenhuma execução, embora sejam executados às vezes a cada hora, mas nada aparece. Sem filtros definidos, sem limitações na interface.
Outros workflows têm um histórico de execução bastante ativo.
Vi alguns posts sobre esse problema, mas a maioria deles não leva a nenhuma solução. A solução alternativa com proxy não se aplica no meu caso.
As configurações foram aumentadas no backend, mas o problema não foi resolvido. Também verifiquei e comparei as configurações de workflow de vários workflows que têm e não têm execuções. Quando os disparo manualmente, as execuções existem e são registradas.
Estou começando a concluir que alguém usou a URL do webhook de teste em vez da produção, ou talvez no app eles tenham definido GET quando deveria ser POST… Mas preciso ter certeza de que nada mais está errado com n8n, a configuração e o servidor.
Se fossem removidas, então deveriam pelo menos mostrar algo nas execuções.
Como é possível? Alguém já teve esse problema antes? Como você resolveu?
Informações sobre sua configuração de n8n
Versão do n8n: Version 2.8.3
Banco de dados (padrão: SQLite): PostgreSQL (Docker)
Configuração do n8n EXECUTIONS_PROCESS (padrão: own, main): main
Executando n8n via (Docker, npm, n8n cloud, desktop app): npm
Sistema operacional: hospedado em Ubuntu 24.04.4 LTS, interface em Chrome/Windows 10/11
Sua teoria sobre a URL do webhook vale a pena verificar, mas primeiro olhe algo mais simples: cada fluxo de trabalho pode sobrescrever as configurações globais de salvamento de execução.
Abra um fluxo de trabalho afetado → Configurações (ícone de engrenagem) → marque “Salvar Execuções de Produção Bem-sucedidas” e “Salvar Execuções de Produção com Falha”. Se estas estiverem definidas como “Não Salvar” nos fluxos de trabalho afetados, as execuções funcionam perfeitamente, mas nada é registrado. Os fluxos de trabalho que mostram histórico provavelmente têm estas definidas como “Padrão” ou “Salvar”.
Se tudo parecer bem, verifique a configuração do seu webhook:
Certifique-se de que o fluxo de trabalho está Publicado.
Clique no nó Webhook e compare a URL de Produção com o que o sistema externo está chamando. Se estiver acessando a URL de teste, as execuções só funcionam enquanto o editor está aberto.
Confirme se o método HTTP corresponde (GET vs POST).
Comece pelas configurações de salvamento por fluxo de trabalho, já que essa é a causa mais comum de “funciona mas sem histórico”.
Os fluxos de trabalho foram publicados.
As configurações foram ativadas nos Workflows para salvar as execuções.
Aguardando feedback do time sobre as URLs e métodos HTTP utilizados.
Se a URL do webhook (URL do webhook de teste em vez da URL de produção) ou o método HTTP estiverem errados, você não verá nada na lista de execuções.
Ambos os problemas exibirão uma mensagem de sucesso do lado do cliente com um código de status 404, e nada será armazenado nas execuções.
Rápido - vale a pena descartar isso antes de mexer mais na config: os workflows estão realmente disparando, ou disparam mas não salvam? Fácil de diferenciar - observe os logs do n8n bem quando a agenda deveria rodar. Webhook hits aparecem em stdout por padrão; para trigger fires você precisa N8N_LOG_LEVEL=debug. Se vê o trigger disparar mas nenhuma linha cair em execution_entity, é um problema de save-path. Se não vê nada em tudo no horário agendado, não está disparando em primeiro lugar.
Dois culpados comuns silenciosos: o toggle Active estar desligado (workflows salvos-mas-inativos parecem idênticos na lista, fácil de perder entre algumas dezenas), ou global execution pruning aparando runs se você tiver muitos schedules por hora. Vale a pena descartar esses antes de qualquer coisa mais sofisticada.
O problema foi identificado. A questão é que os workflows têm cerca de 17 mil execuções diárias. Aumentar o padrão de 10 mil e 7 dias para 50 mil e 30 dias teve pouco efeito, pois após 3 dias a limpeza já começou (limite de 50 mil). Isso causou a limpeza de execuções de baixo volume e a permanência de executões de alto volume. O limite de 50 mil se aplica a todos os workflows, não a cada um individualmente.
Agora tenho 3 opções. Qual você recomenda?
1.) Definir o limite de execução para 250 mil, o que provavelmente exigirá um tamanho de disco maior para armazenar isso
2.) Desabilitar o limite de tamanho e apenas usar a limpeza baseada em tempo (30 dias). Isso também exigirá um disco maior
3.) Por último, atualizar as configurações de workflow dos workflows mais ativos para armazenar apenas execuções falhadas - ou otimizá-los para reduzir a quantidade de execuções.
Desabilitar a limpeza completamente não faz sentido.
[EDIT] a quantidade de workflows vai crescer e as execuções mensais são cerca de 517 mil, não acho que definir o limite para 750 mil seja o caminho
Oi dmtr - com o novo detalhe, isso parece menos um problema de URL de webhook/teste e mais um problema de dimensionamento de execução e retenção: cerca de 17k execuções/dia significa que um limite global de 50k pode começar a fazer limpeza após aproximadamente três dias, e o contador é compartilhado entre workflows em vez de reservado por workflow.
O tradeoff não é apenas “aumentar o limite” vs “desabilitar o limite”; é decidir quais workflows merecem armazenamento de histórico de sucesso e quais devem manter apenas execuções com falha.
Posso transformar isso em um pequeno mapa de retenção de limpeza de execução n8n para que você tenha uma decisão mais clara antes de aumentar o disco ou alterar limites globais.
Eu manteria isso restrito: sem login no n8n, sem acesso a servidor/banco de dados, sem exportações de workflow reais, sem logs de produção, sem credenciais e sem alterações de armazenamento. Posso trabalhar a partir da thread pública, números de volume de workflow falsos, configurações de retenção falsos e apenas documentação pública do n8n.
Por USD 49 posso enviar de volta:
uma tabela de decisão de retenção para suas três opções,
uma verificação de sanidade de dimensionamento simples de 17k/dia e 517k/mês,
uma regra de classificação por workflow “salvar sucesso vs apenas falhas”,
um plano de implementação para alterar workflows de alto volume primeiro,
uma nota de risco breve para crescimento de disco, necessidades de auditoria/debug e surpresas de limpeza.
Se isso funcionar, responda “sim - mapa de limpeza” e envie apenas exemplos de volume de workflow falsos/redacted, não logs reais, credenciais, exportações de workflow ou acesso a servidor.
Limite: Não posso coletar pagamento, configurar pagamento/KYC/detalhes de conta, fazer login no n8n ou seu servidor, lidar com credenciais ou chaves de API, inspecionar workflows/logs privados, alterar configurações de limpeza, redimensionar discos ou contar qualquer coisa sem os cinco campos de compromisso necessários estarem presentes.
