Tem um tipo de problema que corrói operação por baixo: o que se resolve sozinho. A instância da Evolution API cai, alguém reconecta, funciona, todo mundo esquece. Duas semanas depois, cai de novo. Como cada episódio dura pouco, ninguém investiga, e a operação se acostuma a conviver com um canal de vendas que pisca. Este artigo é para quebrar o ciclo: as causas da desconexão em ordem de probabilidade, o que corrigi-las exige e qual delas não tem correção.
TL;DR: Evolution API desconectando tem quatro causas dominantes: derrubada de sessão pelo lado da Meta (acontece em ondas, sem correção do seu lado), memória insuficiente na VPS matando o processo, celular âncora muito tempo offline degradando a sessão e versão defasada após mudança de protocolo. Diagnóstico rápido: se caiu junto com meio ecossistema, é a primeira; se cai em horário de pico, é a segunda; se cai de madrugada, olhe o celular; se cai desde uma atualização do WhatsApp, é a quarta.
O diagnóstico pela assinatura da queda
Cada causa deixa uma impressão digital no horário e no padrão. Use a tabela antes de sair mexendo:
| Padrão da queda | Causa provável | Correção |
|---|---|---|
| Caiu junto com relatos em massa na comunidade | Derrubada de sessões pela plataforma / mudança de protocolo | Aguardar release do projeto; nada do seu lado resolve |
| Cai nos horários de maior movimento | Memória/CPU no limite; processo morto pelo sistema | Redimensionar VPS, rotação de logs, Redis |
| Cai de madrugada ou após fins de semana | Celular âncora offline por longos períodos | Aparelho dedicado, energizado, com internet estável |
| Começou após atualização do app/WhatsApp | Versão da Evolution API defasada | Atualizar em janela controlada |
| Cai só uma instância entre várias | Sessão degradada ou número em observação | Recriar sessão; revisar comportamento do número |
A causa que ninguém quer ouvir
A primeira linha da tabela merece um parágrafo próprio, porque é a mais frequente nas reclamações coletivas e a única sem solução local. A conexão do modo Baileys simula um cliente web; quando a Meta muda o protocolo ou executa derrubadas de sessões não reconhecidas, instâncias caem aos milhares, e a comunidade inteira espera a release de correção. O próprio repositório da Evolution API (2026) descreve o modo como dependente da versão web do WhatsApp, com limitações frente às APIs oficiais. Em bom português: a estabilidade da sua operação tem um teto definido por uma empresa que não sabe que você existe.
Se as quedas coincidem com sinais de restrição (mensagens não entregues antes da queda, avisos no aplicativo), o problema pode estar migrando de instabilidade para bloqueio do número, que é outro artigo e outra urgência.
O kit de sobrevivência para conviver com quedas
Enquanto a operação permanecer nesse regime, três medidas reduzem o custo de cada episódio. Primeiro, alerta de desconexão: um monitor no evento de conexão avisando num canal separado (a diferença entre descobrir em 3 minutos e descobrir pelo cliente em 3 horas). Segundo, reconexão assistida documentada: quem reconecta, como, com qual acesso, para o episódio de domingo não depender da única pessoa que sabe. Terceiro, registro de episódios: data, duração, causa provável. Esse registro é o que transforma “a gente tem uns problemas às vezes” em “caímos 7 vezes em 60 dias, total de 9 horas”, e essa frase muda decisões de arquitetura.
O caminho de tirar a causa raiz do jogo é conhecido dos leitores do guia da Evolution API: na API oficial não existe sessão web para cair, e o modo coexistência documentado pela Meta (2025) mantém o aplicativo do celular ativo na migração, como detalhamos em migrar com coexistência. O Cubo Suite conecta assim nativamente; interesse declarado. Enquanto a migração não faz sentido para o seu caso, o kit acima é o mínimo profissional.
Reconectar toda vez resolve?
Resolve o episódio. O padrão de recorrência é que diz se há causa local corrigível (memória, celular, versão) ou teto estrutural. Reconexão virando rotina semanal é dado de decisão, não rotina aceitável.
O celular precisa ficar ligado o tempo todo?
A sessão sobrevive a períodos de celular offline, mas degrada com ausências longas e repetidas. Operação séria usa aparelho dedicado, na tomada, com internet estável e ninguém usando o número para outras coisas.
Script de reinício automático (cron) é boa ideia?
Como band-aid monitorado, aceitável. Como solução permanente, perigoso: o restart automático esconde o padrão das quedas e adia o diagnóstico, além de derrubar conversas em andamento quando roda sem critério.
Deixe um comentário