Autodiagnóstico · Não é uma varredura
Um autodiagnóstico guiado quando o bot para
Responda a algumas perguntas sobre um bot mudo, lento, com pagamento falhando ou parado porque o desenvolvedor anterior sumiu. A resposta é em linguagem simples: causas prováveis, o que você pode verificar, o risco e quando vale assumir o bot e manter hospedagem mensal.
Cinco perguntas
O que esta página não faz
A lista é um script no navegador. Ela liga os sintomas que você marca a falhas comuns da Bot API do Telegram e da hospedagem comum. Ela não chama getMe, getWebhookInfo nem nenhum endpoint do WhatsApp, e não mede o seu servidor. Ler um bot que está no ar exige o token e o servidor, exatamente o que esta página recusa receber.
Se uma linha de log contém um token, não cole essa linha num chat, num chamado ou num formulário. Tokens costumam ser impressos por acidente quando o processo inicia. Quem ainda vê o bot no BotFather pode revogar um token que vazou e colocar o valor novo só no servidor.
Webhook e polling longo
Um bot de Telegram não roda nos servidores do Telegram. Algum programa seu espera em getUpdates (polling longo) ou recebe POST HTTP no endereço registrado com setWebhook. A Bot API trata os dois como alternativas: enquanto o webhook existe, getUpdates não entrega a fila. Um bot que ainda abre no aplicativo pode ficar mudo porque esse programa saiu.
getWebhookInfo informa o endereço atual, quantas atualizações esperam (pending_update_count) e o último erro de entrega (last_error_date, last_error_message). Uma fila que cresce significa que o Telegram ainda tem as atualizações e o seu endereço não as aceitou. Para as pessoas, isso é silêncio. Esta página não chama getWebhookInfo por você; quem já tem o token pode chamar, sem enviar o token para cá.
Duas cópias do mesmo token devolvem 409 Conflict. Uma cópia comum é um notebook deixado em polling durante a noite enquanto o servidor também consulta, ou um servidor antigo cujo webhook não foi removido enquanto o novo faz polling. Por fora, as respostas vêm e somem.
TLS vencido
A entrega por webhook precisa de HTTPS na porta 443, 80, 88 ou 8443, e de um certificado que o Telegram consiga verificar. Certificado vencido, ou um nome que não combina com o host, falha no TLS, antes do seu código rodar. O painel pode dizer que a máquina está ligada o tempo todo. Se você já conhece esse endereço público, o navegador mostra o aviso de certificado sem nenhum segredo. Se não conhece o endereço, não chute.
Certificados que se renovam sozinhos param de renovar quando a tarefa de renovação morre, quando a porta 80 fecha ou quando o domínio deixa de apontar para a máquina. O código do bot não mudou. A fechadura da porta mudou.
Token revogado
Revogar o token no BotFather faz api.telegram.org responder 401 Unauthorized ao token antigo. O processo continua usando o valor que está no ambiente. Reiniciar sem trocar esse valor falha do mesmo jeito. O token novo fica no ambiente do servidor, com permissão que não seja de leitura para todo mundo, e em nenhum outro lugar. Ele não pertence a esta página.
Se você não abre o bot no BotFather, não revoga o token nem muda o webhook. O nome de usuário pode continuar abrindo para quem já tem o chat, enquanto o controle da identidade fica com quem ainda tem o BotFather. Um bot novo é um nome novo e uma conversa nova. Os chats antigos não mudam de lugar. O mesmo corte vale quando o desenvolvedor anterior tem o login do servidor: a máquina pode ser desligada ou a senha trocada, e a janela do chat não mostra isso.
Limites e a janela de pagamento
Enviar rápido demais devolve 429 Too Many Requests e retry_after, um número de segundos. A orientação publicada do Telegram é ficar perto de uma mensagem por segundo num único chat e não passar de cerca de 20 mensagens por minuto no mesmo grupo. Um loop de disparo que ignora o 429 parece um bot travado. Não é um servidor morto.
Pagamentos são mais rígidos do que mensagens comuns. O bot tem de responder ao pre_checkout_query em 10 segundos e não pode entregar nada até chegar successful_payment. Um processo preso num bloqueio de banco perde essa janela. A pessoa vê o pagamento falhar, ou paga e não recebe. O identificador usado depois num reembolso em Stars fica com o bot. Este site não o vê e não recebe nem repassa dinheiro. A página de Telegram descreve Stars só nesse sentido mais estreito de bens digitais.
O processo no servidor
As paradas comuns são comuns. O processo saiu e nada o iniciou de novo. O kernel o matou por memória. O disco encheu. O SQLite respondeu database is locked porque dois processos abriram o mesmo arquivo. Um painel que diz “em execução” fala da máquina virtual, não do seu programa. Se o servidor não abre HTTPS para api.telegram.org, o polling falha enquanto o processo continua de pé. O webhook falha no outro sentido: o Telegram não consegue entrar.
Um supervisor que reinicia o processo quando ele sai não conserta um token ruim ou uma configuração ruim. O log é o que distingue uma queda de um ciclo de reinício. Não encaminhe uma linha de log que contenha um token.
WhatsApp é a mesma forma, outra porta
Um bot na Cloud API oficial do WhatsApp só vê as mensagens que a Meta entrega no webhook daquele app comercial. Se o endereço está fora ou não responde, as conversas novas não chegam ao programa. O app e o token ficam numa conta comercial da Meta. Um token de curta duração para quando vence. Se só o desenvolvedor anterior abre o app, o token não é trocado até esse acesso ser seu.
Esta página não repete prazos de revisão da Meta, regras de modelo nem preços por país. Isso é da Meta; onde este site descreve, está na página de WhatsApp, e a conta vai para o dono da conta. Não cole um token de usuário do sistema num formulário.
Quando parar de verificar e entregar
Continue verificando se você ainda abre o servidor e o código e a falha começou hoje. Olhe o processo, o certificado e se uma segunda cópia está rodando.
Entregue quando um cliente pode já ter pago, quando você não abre o servidor e o código ao mesmo tempo, ou quando a única pessoa que podia não responde. Assumir começa pela lista de quais contas ainda existem, e depois pelo conserto ou pela reconstrução do caminho que importa. Hospedagem mensal é o acordo seguinte e separado: alguém nota um processo morto, guarda backups e acompanha mudanças de API. Assumir e corrigir começa com um check gratuito e um orçamento do problema. A página de hospedagem é mensal, com preço conforme a complexidade, confirmado com o escopo. A página de assumir descreve essa avaliação. Esta lista não é um orçamento e não é uma varredura.
Leve a leitura ao formulário.
Diga a plataforma, o que o bot faz agora e o que você ainda abre. Um quadro aproximado basta para começar a avaliação.