Por que o lead fica sem resposta no Chatwoot com n8n? O webhook que nunca virou execução

Quando o cliente manda mensagem no Chatwoot, o atendente de IA não responde e a conversa termina na fala dele, o motivo mais comum que encontrei não é erro no fluxo: o webhook nunca virou execução no n8n. O Chatwoot espera 5 segundos pela resposta, desiste em silêncio, e nada no n8n registra que aquela mensagem existiu. A saída é responder o webhook na hora, processar depois e conferir de tempos em tempos quais conversas ficaram sem resposta.

O que o código do Chatwoot faz

Li o código aberto do Chatwoot em 10 de outubro de 2026. O arquivo lib/webhooks/trigger.rb envia o webhook com open_timeout e read_timeout iguais ao valor da configuração WEBHOOK_TIMEOUT. Se ela não estiver definida, o padrão é 5 segundos.

Sobre repetição, o que está escrito é bem específico: existe um erro marcado como repetível, mas só para webhook de agent bot (o tipo de integração em que o bot responde direto) e só quando o servidor devolve status 429 ou 500. Uma demora que estoura o tempo de espera não entra nessa regra, e nesse arquivo ela cai no tratamento de falha, que registra um aviso no log do Chatwoot. Nos eventos de mensagem criada ou atualizada, o tratamento marca a mensagem como falha (no webhook de caixa de API) ou reabre a conversa (no agent bot). Quem usa webhook de conta comum, sem essas condições, não tem reenvio documentado.

O mesmo WEBHOOK_TIMEOUT aparece no installation_config.yml do Chatwoot como "tempo máximo que o Chatwoot espera a resposta do webhook antes de falhar a requisição", com valor 5. Para webhook de conta comum, o WebhookJob chama o Trigger uma vez, o erro é capturado e registrado como aviso, e não encontrei repetição nesse caminho. O agent bot tem um job próprio que tenta até 3 vezes, com 3 segundos de espera, só para 429 e 500.

O que vi em produção

Num cliente que atende leads pelo WhatsApp com um atendente de IA ligado ao Chatwoot e ao n8n, parte das conversas terminava na fala do lead, sem resposta. Num intervalo de dez dias em agosto de 2026, várias dessas conversas tinham a mesma assinatura: a mensagem existia no Chatwoot e não havia execução correspondente no n8n, que no mesmo instante recebia dezenas de outros webhooks por minuto. Ou seja, o n8n estava de pé e ocupado.

Medi o processo principal do n8n e vi um núcleo de CPU cravado em rajadas de 1 a 4 segundos, com o tempo até o primeiro byte do endpoint de saúde subindo a 1,9 segundo. Uma rajada somada à latência de rede ficava perto do limite de 5 segundos. Depois de aliviar a carga desse processo em setembro de 2026, os casos caíram para uma fração pequena e o mesmo endpoint passou a responder em milissegundos.

Não existe log de acesso HTTP nessa instalação, então não consigo provar o webhook perdido por registro direto. A prova é por exclusão: a mensagem existe no Chatwoot e não existe execução no n8n no intervalo de mais ou menos 20 segundos.

Por que acontece

O Chatwoot só considera entregue o webhook que responde dentro do prazo. O n8n, por padrão, só responde depois de receber e preparar a execução. Se o processo que atende os webhooks está ocupado, a resposta atrasa, o Chatwoot desiste, e o n8n, que talvez nem tenha chegado a registrar a requisição, não guarda rastro nenhum. Esta é a explicação que melhor bate com o que medi; não tenho como provar cada caso individual. Para quem opera, tudo parece normal: nenhuma execução falhou, porque nenhuma começou.

O que fazer

1. Responda o webhook imediatamente. No nó Webhook do n8n, a opção Respond como Immediately devolve a mensagem "Workflow got started" assim que a requisição chega. Se precisar de um corpo específico, use "Using Respond to Webhook node" e coloque o nó logo depois do gatilho, antes de qualquer chamada lenta ao modelo de linguagem.
2. Tire o recebimento da frente do trabalho pesado. No modo fila do n8n, a documentação diz que o processo principal recebe o webhook e gera a execução, que um worker roda. Existe ainda a camada opcional de processadores de webhook, que a documentação descreve como uma forma de escalar só o recebimento. Isso afasta a execução pesada do processo que precisa responder rápido.
3. Meça o tempo de resposta do endpoint de webhook sob carga, não só com o sistema parado. O limite é o seu WEBHOOK_TIMEOUT do Chatwoot, 5 segundos por padrão.
4. Reconcilie, sem processar em dobro. De tempos em tempos, compare as mensagens de entrada do Chatwoot com as execuções de webhook do n8n numa janela de 20 segundos em torno de cada uma. Quem não tem par é lead sem resposta, e o caminho mais seguro é mandar esses casos para uma fila humana ou reprocessar só depois de checar se a conversa já tem resposta do atendente.
5. Proteja contra duplicidade. Responder na hora não faz o Chatwoot reenviar (o reenvio do agent bot só ocorre com 429 ou 500), mas a reconciliação pode reprocessar uma mensagem que chegou atrasada. Use o id da mensagem como chave de deduplicação e confira se já existe resposta antes de gerar outra. O código do Chatwoot envia o cabeçalho X-Chatwoot-Delivery quando há um identificador de entrega, que também serve de chave.

O desenho de ponta a ponta, do Chatwoot à IA e à fila de exceções, está descrito em atendimento no WhatsApp com IA.