Espero que alguém possa ajudar ou pelo menos me apontar na direção certa.
Meu workspace n8n Cloud está offline há mais de uma hora com a tela clássica de 503 “workspace está reiniciando” enquanto diz que minha instância está online. Tenho uma demonstração deste workflow para apresentar muito em breve.
O que aconteceu: Executei meu workflow pela primeira vez, envolve um gatilho do Gmail baixando anexos em PDF + 3 nós de agente de IA (Claude/Anthropic). Parece que atingiu o limite de memória na primeira execução e o workspace simplesmente nunca voltou.
O que já tentei:
Esperei, atualizei, diferentes navegadores, modo incógnito — ainda 503
Verifiquei status.n8n.cloud — nenhum incidente global
Reiniciei manualmente a instância.
Contactei o suporte — recebi uma resposta de bot de IA me dizendo para “otimizar meu workflow”. Pedi para escalar para uma pessoa, mas ainda sem resposta.
A parte frustrante: Eu sei qual é a solução (reduzir limites de tokens, lidar com anexos de forma diferente) — simplesmente não consigo acessar o editor para aplicar porque o workspace está inativo.
Alguém já passou por isso e encontrou uma maneira de fazer a instância voltar sem esperar pelo suporte? Existe uma forma de forçar uma reinicialização a partir do painel de administração que estou perdendo?
Qualquer ajuda é muito apreciada
Informações sobre minha configuração n8n:
Versão n8n: latest
Banco de dados: default
Configuração EXECUTIONS_PROCESS: default (gerenciado pela Cloud)
@PaulRocks 503 stuck-loop geralmente significa que seu pod está fazendo OOM no restart porque o workflow que falha auto-executa quando o n8n o traz de volta — ele trava, tenta novamente, trava de novo. você já tentou o ciclo Suspend → Resume no seu admin do app.n8n.cloud? esse é o único force-restart self-service que a cloud expõe, e o passo de suspend previne a auto-execução para que o pod possa subir limpo antes de qualquer workflow rodar.
obrigado pela dica. Tentei o botão Restart workspace no painel Manage, mas mesmo resultado, ainda preso no loop 503. Confirma o que você disse sobre o pod travando no restart antes de qualquer coisa carregar.
Eu honestamente estou considerando apenas criar uma nova conta n8n Cloud e reconstruir o workflow do zero para bater meu deadline de demo esta semana, mas isso vai me custar uma segunda assinatura. Não é ideal, mas estou ficando sem opções.
Ou talvez fazer upgrade do plano atual seja o único conserto real aqui já que haverá 640 MIB?
Quanto tempo, em geral, o suporte da N8N leva para responder? Se for em um dia, eu poderia esperar. Se for em dois ou mais dias, vai ser realmente complicado para mim.
@PaulRocks não faça upgrade ou crie uma nova conta ainda, o suporte geralmente consegue resetar o pod. envie um email para help@n8n.io com sua URL de instância e “URGENT 503 crash loop” no assunto, mencione que você já sabe que o workflow é a causa do OOM e só precisa que o pod seja reiniciado com o workflow inativo ao retomar. assim ele não vai crashear imediatamente e você consegue corrigir antes de reativar.
a pressão de memória é o problema real subjacente — download de anexos do Gmail + 3 nós de IA acumulando em memória é pesado para o plano starter. quando você voltar, ou alivie o tratamento de anexos ou aumente seu plano. faça a demo primeiro, otimização depois.
Atualização, está funcionando novamente Obrigado pela ajuda
Uma pergunta rápida agora — o que eu deveria modificar no workflow para garantir que isso não aconteça novamente no Starter (320 MiB)?
Configuração atual:
Gmail Trigger com downloadAttachments: true (11 PDFs)
3 agentes Anthropic Claude sequenciais (maxTokens definido para 4096 e 8192)
Structured output parsers em 2 dos 3 agentes
O workflow passa todos os dados pela chain
Você mencionou desabilitar downloadAttachments e fazer streaming via o binary endpoint — poderia explicar como isso funciona na prática? Eu só faço referência aos anexos por ID depois quando eu realmente precisar lê-los?
Também estou aberto a qualquer outra dica de otimização de memória para workflows com muita IA no Cloud. Obrigado novamente
sim exatamente — desativa downloadAttachments no trigger do Gmail para que ele dispare apenas com metadados (ID da mensagem + ID do anexo + nome do arquivo). depois tu adiciona um nó “Get a Message Attachment” do Gmail dentro de um loop SplitInBatches com tamanho de lote 1, assim só um PDF na memória por vez em vez de todos os 11 empilhados.
duas outras coisas pra tentar. reduz maxTokens de 4096/8192 para 1024-2048 a menos que tu realmente precise desse comprimento, corta bastante memória por chamada do agent. e coloca um nó Set depois de cada passo de IA que mantém APENAS o campo que tu precisa ir pra frente — n8n carrega todos os dados de entrada através de cada nó por padrão então cada output do agent se empilha em cima de todo payload anterior.
Obrigado pela ajuda