Temos um problema com webhooks em múltiplos workflows. Há múltiplas ocorrências, sempre por volta das 12h/13h ~ 12h20/13h20, onde alguns webhooks simplesmente não são chamáveis e o n8n lança “There was a problem executing the workflow” (Houve um problema ao executar o workflow). Ou o backend executa em um timeout, nenhuma execução é registrada (mesmo com o registro de execuções ativado). Não há mais mensagem de erro, apenas esta genérica. Existe um lugar onde posso ver mais informações sobre este erro na minha instância do n8n?
O único lugar para encontrar o erro “real” é nos Logs de Serviço do Render.com.
O que procurar: Acesse seu Dashboard do Render →→ seu serviço n8n →→ Logs.
Palavras-chave Específicas: Procure por SQLITE_BUSY, database is locked, Out of Memory, Killed ou Segmentation fault próximo aos timestamps 12:00 AM/PM.
Dica Pro: Para obter ainda mais detalhes, adicione a variável de ambiente N8N_LOG_LEVEL=debug às suas configurações do Render e reinicie. Isso forçará o n8n a imprimir eventos internos mais verbosos nos logs do Render.
Com base em sua descrição, esse comportamento é tipicamente causado por uma de duas coisas: Bloqueio de Banco de Dados ou Falta de Memória (OOM).
Esta é a correção recomendada:
Migrar para PostgreSQL: SQLite não foi projetado para concorrência em produção. O Render fornece um banco de dados PostgreSQL gerenciado. Migrar para Postgres remove completamente o problema do “bloqueio de escrita” e é a recomendação padrão para qualquer instância n8n que lida com webhooks de produção. Isso resolverá permanentemente os timeouts das 12:00 e os erros genéricos “problem executing”.
Desculpa, cometi um erro, já estamos usando Postgres.
A memória também não apresenta picos naqueles momentos e não há outras entradas de log no serviço de render além daquelas “There was a problem executing the workflow”.
@Florian_Glappa Eu esperaria que esse erro acionasse algo nos registros do n8n. É possível que o Render faça um backup/snapshot por volta da meia-noite? Uma janela de 20 minutos em torno do mesmo horário aponta para algo ambiental em vez de um bug do lado da aplicação.
Complementando o ângulo ambiental do Jon — há também um padrão do lado da aplicação que se encaixa perfeitamente nos seus sintomas e ainda não foi mencionado: 0 0,12 * * * é uma das expressões cron mais comuns que existem. Se algum workflow na sua instância (não apenas os que estão falhando) tem um Schedule Trigger disparando às 00:00 e 12:00, um job pesado duas vezes por dia pode saturar brevemente a instância, e os webhooks recebidos são o que falha visivelmente. Vale a pena fazer um inventário rápido de cada Schedule Trigger em todos os workflows, depois verificar a lista de execuções filtrada para aquelas janelas de tempo: sempre há uma execução agendada em andamento quando os webhooks caem?
A segunda coisa que corresponde ao seu “nenhum dado de execução registrado apesar da gravação ativada”: esgotamento do pool de conexão do Postgres. O pool padrão do n8n por processo principal é pequeno, e quando várias execuções começam no mesmo momento o pool fica vazio — novas execuções podem falhar antes do n8n conseguir escrever qualquer coisa na tabela de execuções, e o erro volta para o chamador do webhook sem muita coisa chegando nos logs do serviço. Isso explicaria por que você vê quase nada nos logs do Render. Duas verificações: aumente DB_POSTGRESDB_POOL_SIZE (por exemplo, para 10) e veja se o padrão muda, e procure pelos logs do lado do Postgres (os logs do banco de dados do Render, não os logs do serviço n8n) por erros de conexão ou picos de latência naquelas janelas — um backup de banco de dados gerenciado também apareceria lá, o que confirmaria a teoria do Jon sem adivinhar.
E como é tão previsível: observe ao vivo uma vez. docker logs -f (com debug ativado, como o kjooleng sugeriu) das 11:55 às 12:25 vai te dizer mais do que um dia de histórico, além de filtrar a lista de execuções por status “crashed” — essas nem sempre aparecem onde você espera.
Se o inventário de cron revelar um job duas vezes por dia, o conserto usual é apenas movê-lo para um horário ímpar (estilo 03:17) e fazer batch dele. Escalonar agendamentos em minutos ímpares é um bom hábito em qualquer n8n de instância única de qualquer forma.
Opa, essa foi uma dica muito boa, obrigado! Encontrei um cron que inicia às 00:05 e 12:05, que geralmente executa por 15 minutos e consumia uma quantidade ridícula de memória. Refatorei isso agora, acho que era isso. Muito obrigado!
