Erros de migração comuns e como corrigi-los
· Por AI Compare
Os dez erros que as equipas encontram depois de mudar para o n8n, e como corrigir cada um.
Os erros mais comuns depois de migrar para o n8n
1. «Workflow could not be activated» ou o webhook não recebe dados
Causa: a app de origem continua a apontar para o URL do webhook de teste, ou o workflow não está ativo.
Solução: os webhooks do n8n têm um Test URL (só funciona enquanto clica em «Listen for test event») e um Production URL (só funciona com o workflow ativo). Ative o workflow e cole o Production URL na app de origem. No n8n com alojamento próprio, defina WEBHOOK_URL para que o n8n mostre o seu domínio público e não localhost.
2. Os agendamentos correm à hora errada
Causa: o fuso horário não está definido.
Solução: defina GENERIC_TIMEZONE (alojamento próprio) ou o fuso horário do workflow em Workflow settings.
3. Os nós correm vezes a mais (ou a menos)
Causa: perceber mal os items. O n8n executa cada nó uma vez por item recebido. Um passo «Looping» migrado ou um iterador do Make adicionado por cima provoca processamento duplicado.
Solução: remova os ciclos desnecessários. Use o Aggregate para juntar items quando precisar de uma só saída (por exemplo, uma mensagem no Slack a resumir 20 linhas), ou ative Execute Once num nó.
4. «Cannot read properties of undefined» nas expressões
Causa: o campo referenciado não existe em alguns items, ou referenciou o nó errado.
Solução: use encadeamento opcional e valores predefinidos: {{ $json.customer?.email ?? '' }}. Referencie explicitamente os nós anteriores: {{ $('Stripe Trigger').item.json.data.object.id }}.
5. Erros de OAuth: «invalid_grant», «redirect_uri_mismatch», tokens a expirar
Causas e soluções:
- redirect_uri_mismatch: o URL de redirecionamento na consola de programador da app tem de coincidir exatamente com o que aparece na credencial do n8n (https, domínio, caminho).
- invalid_grant ao fim de 7 dias (Google): a sua app OAuth da Google está em modo «Testing». Publique-a ou use uma app Internal no Google Workspace.
- Scopes em falta: adicione os scopes necessários e volte a ligar a credencial.
Veja o guia de credenciais.
6. Registos duplicados depois da mudança
Causa: o Zap ou cenário antigo e o novo workflow correram ao mesmo tempo, ou um webhook foi reenviado.
Solução: desligue a automação antiga no momento em que ativa a nova. Use upserts (criar ou atualizar) e guarde os IDs externos para tornar os workflows idempotentes.
7. Os formatos de data são diferentes dos do Zapier
Causa: o Formatter do Zapier devolvia um formato específico; o n8n devolve datas ISO.
Solução: formate explicitamente: {{ $json.date.toDateTime().toFormat('dd/MM/yyyy') }}.
8. Ficheiros binários em falta (anexos, PDFs)
Causa: os dados do ficheiro estão na propriedade binary do item, não no JSON, e um nó intermédio descartou-os.
Solução: verifique o nome da propriedade binária (por exemplo attachment_0 ou data) e indique-o no nó que a recebe. Alguns nós (como o Edit Fields) precisam de ter «Include binary data» ativado.
9. Erros de limite de pedidos (429)
Causa: o n8n processa os items depressa e atinge limites de API que a sondagem mais lenta do Zapier evitava.
Solução: ative Retry On Fail com espera entre tentativas, use Loop Over Items com tamanho de lote e um nó Wait, ou as opções de lotes do próprio nó.
10. A instância com alojamento próprio fica sem memória
Causa: ficheiros grandes, payloads JSON volumosos ou muitas execuções em simultâneo num servidor pequeno.
Solução: aumente a RAM, processe os dados em lotes, evite manter binários grandes em memória (use o modo binário «filesystem») ou passe para o queue mode com workers.
Hábitos de depuração que poupam horas
- Fixe os dados do trigger enquanto constrói, para poder voltar a executar sem novos eventos.
- Abra as execuções falhadas e verifique a entrada e a saída do primeiro nó a vermelho.
- Adicione um workflow com Error Trigger que publica as falhas no Slack com o nome do workflow e um link.
