O sintoma chega sempre pelo pior caminho: o cliente liga irritado dizendo que mandou mensagem ontem e ninguém respondeu. Alguém procura a conversa no sistema e ela não está lá.
Não é o cliente mentindo, e normalmente não é a Meta falhando. É o webhook — o canal por onde as mensagens chegam até a sua plataforma — que não recebeu, ou recebeu e não confirmou.
Esse assunto costuma ser tratado como problema de TI. Ele é, mas tem uma consequência comercial que quase ninguém liga aos pontos: dependendo de quanto tempo a falha durar, você não só perde a mensagem — você perde o direito de responder de graça.
Como o webhook deveria funcionar
O mecanismo é simples. O cliente manda mensagem, a Meta envia uma notificação para o endereço que a sua plataforma cadastrou, e o seu servidor precisa confirmar o recebimento.
A confirmação tem forma exata. A documentação diz que o endpoint deve responder a todas as notificações com 200 OK por HTTPS. Qualquer coisa diferente disso — erro, timeout, servidor fora do ar — é tratada como falha.
Antes disso, na configuração, existe a verificação do endereço: a Meta faz uma requisição com um hub.verify_token, o servidor confere se bate com o token configurado e responde devolvendo o hub.challenge. É por isso que webhook mal configurado nem chega a receber a primeira mensagem.
A janela de 36 horas
Quando a confirmação não vem, a Meta não desiste na hora. A política está escrita assim:
“If any update sent to your server fails, we will retry immediately, then try a few more times with decreasing frequency over the next 36 hours.”
Tenta imediatamente, depois mais algumas vezes com frequência decrescente, ao longo das 36 horas seguintes. E então:
“Unacknowledged responses will be dropped after 36 hours.”
Depois de 36 horas, a notificação é descartada.
Isso é generoso do ponto de vista técnico — uma queda de algumas horas se resolve sozinha quando o servidor volta, e ninguém percebe. Mas cria um cenário que vale conhecer: uma queda longa, um fim de semana prolongado com o servidor derrubado, uma migração malfeita na sexta-feira. Passadas 36 horas, aquelas mensagens não voltam. Não existe endpoint para pedir o que ficou para trás.
E, do ponto de vista do cliente, ele escreveu para a sua empresa e foi ignorado.
A parte que ninguém conecta
Aqui está o detalhe que transforma um problema técnico em prejuízo, e ele aparece quando você coloca os dois prazos lado a lado.
A janela de atendimento de 24 horas conta a partir da mensagem do cliente. Ela não espera o seu servidor voltar, não pausa durante a queda, não sabe que você teve um problema.
A janela de reenvio é de 36 horas.
Ou seja: existe uma faixa de 12 horas em que a notificação ainda vai chegar — e a janela já fechou. Você recebe a mensagem, vê que o cliente perguntou algo às 9h de ontem, e descobre que não pode mais responder com texto livre. Só com template aprovado, que é cobrado.
E isso piora a partir de 1º de outubro de 2026, quando as mensagens de serviço passam a ser cobradas: a conversa que você recuperar depois da queda passa a ter custo em cada mensagem, não só na primeira.
Uma queda de servidor deixou de ser só indisponibilidade. Virou linha de custo.
A ordem não é garantida
Outro ponto documentado que explica um sintoma comum: não existe garantia de ordem.
A documentação orienta a tratar cada notificação individualmente, avisando que o agrupamento não pode ser garantido. Na prática, isso significa que as notificações podem chegar fora da sequência em que os eventos aconteceram.
O efeito visível é a conversa embaralhada: a resposta do cliente aparecendo antes da pergunta, o status de “lida” chegando antes do de “entregue”, o histórico com a ordem trocada quando o volume aperta.
Sistema bem feito resolve isso ordenando pelo carimbo de tempo do evento, não pela ordem de chegada. Sistema improvisado mostra a bagunça para o atendente — que perde tempo entendendo a conversa antes de responder.
Como saber que está acontecendo
O jeito ruim é o mais comum: descobrir pelo cliente.
O que evita isso não é sofisticado:
Monitorar a taxa de resposta 200 do endpoint. Se ela cair, alguém precisa ser avisado em minutos — não no dia seguinte.
Alertar quando parar de chegar mensagem. Toda operação tem um ritmo. Se numa terça às 14h o volume de entrada cai a zero, é falha, não silêncio de clientes.
Acompanhar conversas sem resposta. Uma conversa aberta há horas sem ninguém ter respondido é o sintoma final. Se ninguém olha esse número, a falha só aparece quando vira reclamação.
Responder rápido, sempre. Além de tudo que já se sabe sobre conversão, responder cedo reduz a exposição: quanto antes você entra na janela, menos uma queda te empurra para fora dela.
O que fazer depois de uma queda
- Confirme por quanto tempo ficou fora. Menos de 36 horas significa que o pendente foi reentregue. Mais que isso, houve perda definitiva.
- Priorize por janela, não por ordem de chegada. Quem escreveu há menos de 24 horas ainda dá para responder com texto livre — e de graça, até outubro. Esses primeiro.
- Para quem ficou fora da janela, use template. É o único caminho, e vale ter um template de retomada aprovado justamente para isso. Aprovação leva até 24 horas, então criar na hora da crise não funciona — assunto de template reprovado e como recorrer.
- Avise quem ficou sem resposta. Um “desculpe a demora” resolve mais do que parece, e evita a reclamação pública.
- Descubra a causa antes de considerar resolvido. Servidor que caiu uma vez cai de novo.
O ponto que interessa a quem não é técnico
Se você não opera servidor, a lição prática deste artigo é uma pergunta a fazer ao seu fornecedor:
“O que acontece com as minhas mensagens se o webhook de vocês ficar fora do ar? Vocês monitoram isso e me avisam, ou eu descubro pelo cliente?”
A resposta separa quem tem infraestrutura de quem tem software rodando. E vale reparar que o custo dessa diferença não aparece na mensalidade — aparece nas conversas que ninguém respondeu e nos templates pagos para retomar quem já estava falando com você de graça.
Onde a gente entra
Esse é exatamente o tipo de coisa que você contrata um parceiro para não precisar pensar.
Com o AtendeChat, seu WhatsApp roda na API Oficial com a operação em volta: as conversas chegam numa fila com dono, ficam no histórico centralizado da empresa — não no aparelho de quem atendeu — e aparecem em relatórios que mostram o que entrou, o que foi respondido e o que está esperando. É essa visibilidade que faz uma falha virar um alerta em vez de virar um cliente perdido.
Somos parceiros oficiais da Meta e conduzimos com você a verificação de negócio, o registro do número e a aprovação dos templates — incluindo os de retomada, que são o que salva a operação quando alguma coisa sai do lugar.
Se hoje você não sabe dizer quantas conversas entraram ontem e quantas ficaram sem resposta, fale com a gente: esse é o número que costuma revelar o problema antes de o cliente revelar.