Cloud: executor de tarefas fora do ar por 7+ horas, todos os nós Code expiram após 66s

Perguntas
1

Descreva o problema/erro/pergunta

Desde 2026-08-26 06:00 UTC, toda execução em produção na minha instância Cloud
que contém um nó Code falha após exatamente 66 segundos. O nó Code nunca
é atribuído a um executor de tarefas.
Instância: brunoclozel.app.n8n.cloud
Plano: trial, 6 dias restantes, 113/1000 execuções usadas
Cronograma:

  • 03:00 UTC - última execução bem-sucedida (id 131)
  • 06:00 UTC em diante - todo fluxo de trabalho agendado falha (ids 132 a 138)
  • 12:50, 12:57, 13:03 UTC - tentativas manuais, mesma falha (ids 142, 143)
    Nada mudou do meu lado entre o último sucesso e a primeira falha.
    São pequenos fluxos de trabalho agendados que vinham funcionando bem há 9 dias.
    O detalhe importante: fluxos de trabalho SEM um nó Code ainda são executados normalmente.
    Um fluxo de trabalho de tratamento de erro feito apenas com um Error Trigger e um nó Telegram
    completou em 0,4s às 13:04 UTC (id 144), na mesma instância, no mesmo
    horário em que os outros estavam expirando. Então a falha é isolada do executor
    de tarefas, não dos meus fluxos de trabalho e não da instância como um todo.
    Não estou executando tarefas Code longas ou em massa - o nó em questão constrói uma
    cadeia curta de ~10 linhas de uma Tabela de Dados e retorna em ~20ms quando o
    executor está saudável.
    status.n8n.cloud não reporta nenhum incidente.

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu fluxo de trabalho

Task request timed out

Your Code node task was not matched to a runner within the timeout period
(waited 66 seconds). This indicates that the task runner is currently down,
or not ready, or at capacity.

Stack:
Error: Task request timed out
    at LocalTaskRequester.requestExpired (task-requester.ts:310:17)
    at LocalTaskRequester.onMessage (task-requester.ts:276:10)
    at TaskBroker.handleRequestTimeout (task-broker.service.ts:179:50)

Compartilhe a saída retornada pelo último nó

Último nó executado: o nó Code. Ele não produziu nenhuma saída.
O nó imediatamente anterior (Data Table, get rows) retornou suas linhas
normalmente, então a cadeia está saudável até o ponto em que o nó Code passa
para o executor.

Informações sobre sua configuração n8n

  • versão n8n: n8n Cloud (gerenciado, atualizado automaticamente)
  • Banco de dados (padrão: SQLite): padrão gerenciado n8n Cloud
  • configuração n8n EXECUTIONS_PROCESS (padrão: own, main): n/a - n8n Cloud
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop): n8n cloud
  • Sistema operacional: n/a - n8n Cloud
2

Oi @Bruno_Clozel Bem-vindo!
O executor não está inativo, 2.37.1 quebra o nó JavaScript Code, então não há nada em sua instância para reprovisionar.

2.37.1 é a track Beta e 2.36.7 é a Stable atual, então a versão que você quer é menor do que a que você está usando. Abra o painel Cloud, vá para Gerenciar > Workspace > Atualizações e manutenção, defina Release track para Stable, escolha 2.36.7 no menu suspenso de versão n8n e selecione Alterar versão. Isso reinicia o workspace por um ou dois minutos.

3

Seus testes apontam fortemente para um problema no executor de tarefas (task-runner) e não em um problema de fluxo de trabalho ou Tabela de Dados. Como fluxos de trabalho sem nós de Código ainda estão funcionando normalmente e o mesmo nó de Código funciona quando o executor está saudável, o timeout de 66 segundos parece ocorrer enquanto aguarda um executor aceitar a tarefa.

O fato de que as tentativas manuais mostram o mesmo comportamento também torna uma falha temporária no nível do fluxo de trabalho menos provável.

4

Obrigado, é exatamente isso. Eu estava na trilha Beta sem perceber, com o intervalo de atualização configurado como “Cada novo lançamento”, então recebi a versão 2.37.1 assim que foi lançada.

Acabei de mudar: trilha Beta → Estável, versão 2.36.7. O Workspace está reiniciando agora. Vou relatar aqui se os nós Code se recuperam, para que esse tópico tenha uma resposta confirmada.

Uma observação para quem encontrar isso depois: status.n8n.cloud permaneceu verde e 100% o tempo todo, e a Visão Geral da Cloud mostrou a instância como saudável. Nada do meu lado indicava um problema. O único sintoma visível era cada nó Code atingindo o tempo limite após exatamente 66 segundos, enquanto os workflows sem um nó Code continuavam rodando normalmente em menos de um segundo.

Também vale a pena sinalizar para o time: abri um ticket por email e a resposta de primeira linha da IA me disse “não há ação de autoatendimento disponível para resolver uma tarefa do task runner falha ou indisponível” e escalou para um humano com um SLA de 3 dias. A correção real foi uma mudança de versão de dois minutos que eu poderia fazer sozinho. O fórum me deu uma resposta correta em minutos; o canal de email me mandou esperar.