N8n Cloud: Webhooks de produção retornam erro 500 e Schedule Trigger não cria execuções

Questions
1

Olá,

Estou enfrentando um problema que parece estar relacionado ao ambiente/workspace do n8n Cloud.

Tenho dois comportamentos diferentes acontecendo no mesmo workspace:

  1. Webhooks de produção falham antes de criar uma execução.
  2. Schedule Triggers publicados também não estão criando execuções automáticas.

WEBHOOK DE PRODUÇÃO

Fiz um teste com um workflow novo contendo apenas:

Webhook

  • Método: POST
  • Authentication: None
  • Respond: Immediately

A URL de teste funciona normalmente:

/webhook-test/…

Porém, a URL de produção:

/webhook/…

retorna HTTP 500 com:

{
“code”: 0,
“message”: “There was a problem executing the workflow”
}

O mais importante é que nenhuma execução é criada no histórico do workflow.

Já testei:

  • workflow completamente novo;
  • Webhook node novo;
  • novo path;
  • workflow publicado;
  • sem nenhum node conectado depois do Webhook;
  • autenticação desativada;
  • chamada manual da URL de produção.

A URL de teste funciona normalmente, mas a URL de produção retorna 500 e não cria execução.

SCHEDULE TRIGGER

Como alternativa ao Webhook, alterei uma automação para utilizar Schedule Trigger.

Testei com:

Schedule Trigger

  • intervalo: minutos;
  • a cada 5 minutos;
  • depois também testei a cada 1 minuto;
  • workflow publicado.

O workflow está configurado para salvar:

  • Production executions;
  • Test executions.

Mesmo assim, depois de publicar e aguardar vários minutos, nenhuma execução automática aparece.

As execuções manuais funcionam normalmente.

RESUMO DO COMPORTAMENTO

  • Execução manual: funciona.
  • Webhook Test URL: funciona.
  • Webhook Production URL: retorna HTTP 500.
  • Webhook de produção: não cria nenhuma execução.
  • Schedule Trigger publicado: não cria nenhuma execução.
  • Execuções de produção estão configuradas para serem salvas.
  • Não existe execução com erro.
  • Não existe execução em fila.
  • Simplesmente nenhuma execução de produção é iniciada.

Por esse motivo, parece que o problema ocorre antes de o workflow começar a executar os nodes.

Este mesmo workspace já executava workflows de produção normalmente anteriormente, então não se trata de uma configuração nova.

Alguém já encontrou esse comportamento no n8n Cloud?

Existe a possibilidade de ser algum problema de registro dos triggers, worker de execução, scheduler ou alguma configuração interna do workspace?

Obrigado.

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

image
image1871×822 22.1 KB

image
image1899×779 39.3 KB

image
image1874×752 19.1 KB

2

Oi @Luis_Gustavo_Araujo, enquanto você aguarda uma resposta, aqui estão algumas coisas que podem ajudar:

Recursos sugeridos

Correspondência automática com sua pergunta.

Docs:

Fórum:

@Anshul_Namdev, @kjooleng - vocês já ajudaram com problemas similares antes, podem dar uma olhada?

Sugerido automaticamente pelo bot da comunidade n8n. É um piloto - compartilhe feedback aqui.

3

Hey @Luis_Gustavo_Araujo

A suspeita de um problema no workspace faz sentido, já que tanto o Webhook de produção quanto o Schedule Trigger falham, enquanto os testes manuais funcionam. Mas esse erro 500 é genérico e não confirma qual componente está falhando.

Eu começaria reiniciando o workspace pelo painel do Cloud, na opção “Restart workspace”, e repetindo os dois testes depois que ele voltar. Qual versão do n8n está rodando aí? Se continuar igual após reiniciar, envie para help@n8n.io a URL do workspace, os IDs desses workflows e o horário de uma chamada que retornou 500, com o fuso horário.

4

Como tanto o webhook de produção quanto o cronograma falham e nada é registrado, parece que as execuções de produção não estão sendo iniciadas no seu workspace.

Vale a pena descartar: verifique se o limite mensal de execuções do seu plano foi atingido (execuções de teste geralmente continuam funcionando enquanto as de produção são recusadas); cancele a publicação e republique um fluxo de trabalho após uma reinicialização, depois acesse a URL de produção uma vez; verifique Execuções filtrado para Todos os fluxos de trabalho.

Se nada mudar, envie um e-mail para o suporte com a URL do workspace, IDs dos fluxos de trabalho e a hora exata de um erro 500.

5

Oi @Luis_Gustavo_Araujo,

Este comportamento específico — em que a URL de Teste funciona perfeitamente, mas a URL de Produção retorna um genérico HTTP 500 com “There was a problem executing the workflow” sem registrar nada no histórico de execução — é um sintoma clássico de um problema de infraestrutura/falta de workers no n8n Cloud, em vez de um erro de design de nó de workflow.

Como tanto o Webhook de Produção publicado quanto o Trigger de Agendamento em segundo plano falham em criar uma entrada de execução, aqui estão os bloqueios exatos de infraestrutura que geralmente causam isso:

  1. Bloqueio de Banco de Dados / Bloqueio de Escrita SQLite/Postgres: Quando um webhook de produção chega, o n8n tenta escrever um novo registro na tabela execution_entity antes de executar o Nó 1. Se o banco de dados do workspace está atualmente travado devido a inchaço transacional, logging pesado ou um processo de worker travado, a inicialização falha silenciosamente no nível do framework principal e descarta o evento com uma resposta 500.
  2. Queda no Registro de Worker: Em ambientes multi-tenant como n8n Cloud, se o scheduler interno/cluster redis perde sua concessão de roteamento ativa para o seu container workspace específico, os triggers publicados (Schedule/Webhook) falham em registrar eventos no loop de execução ativo, enquanto cliques de botão manual (que contornam a fila de workers) continuam funcionando perfeitamente.

O que você deve fazer agora:

  • O Reset Forçado da Cloud: Como @Deepankar sugeriu, use o painel n8n Cloud para parar completamente e reiniciar a instância. Isso encerra quaisquer conexões zumbis ou bloqueios de banco de dados pendentes em segundo plano.
  • A Verificação do Toggle “Save Executions”: Verifique novamente se seu armazenamento de workspace está no limite. Se a cota de disco alocada para seu plano Cloud está 100% cheia, o banco de dados recusará a escrita inicial do estado de execução, causando um HTTP 500 instantâneo no tráfego de produção.

Se você está executando webhooks de empresa críticos e continua enfrentando esses bloqueios de ambiente Cloud, recomendo fortemente fazer a transição para uma arquitetura auto-hospedada Docker Compose com suporte de PostgreSQL dedicado com ledgers de transação e configurações de DLQ Redis para garantir zero perda de dados.

Me avise se o restart completo do workspace cloud traz os workers de volta à vida!