Você pode montar alertas de disponibilidade no Telegram com n8n usando um agendamento, uma consulta HTTP, condições visuais e o nó de envio de mensagens. Não é necessário escrever um programa. O trabalho principal é definir o que significa falha, registrar o estado anterior e avisar uma pessoa que saiba agir.
O fluxo precisa distinguir três situações: o serviço monitorado apresentou problema, a consulta não conseguiu obter resposta ou a própria automação falhou. Se todas virarem a mesma mensagem, a equipe perde tempo investigando o lugar errado. Comece por um endpoint de saúde autorizado e mantenha a consulta separada de qualquer operação que altere dados.
Resumo rápido
- Crie o bot no BotFather e guarde o token nas credenciais do n8n.
- Teste a entrega em uma conversa controlada antes de monitorar produção.
- Use Schedule Trigger, HTTP Request e condições para classificar o resultado.
- Trate respostas HTTP e falhas de conexão por caminhos diferentes.
- Registre o estado para evitar mensagens repetidas e avisar a recuperação.
- Teste também falhas do próprio n8n e do envio ao Telegram.
Defina o que será monitorado e quem recebe o alerta
Escolha um endereço que represente uma função relevante do sistema. Abrir a página inicial não demonstra, por si só, que o cadastro de pedidos funciona. Um endpoint de saúde pode informar se a aplicação está disponível; uma verificação funcional controlada pode avaliar uma dependência específica. Combine esse contrato com quem mantém o serviço.
Documente a resposta esperada, o tempo de espera e a ação necessária quando houver falha. Para um primeiro piloto, uma checagem a cada cinco minutos e uma espera inicial de dez segundos podem servir como parâmetros ilustrativos. Eles não são padrões universais: ajuste conforme a criticidade e os limites da API consultada.
| Sinal observado | Interpretação inicial | Ação sugerida |
|---|---|---|
| Status e conteúdo esperados | Verificação aprovada | Registrar resultado e avaliar recuperação |
| Resposta HTTP inesperada | Serviço respondeu fora do contrato | Informar código e responsável |
| Falha de conexão ou timeout | Não foi possível concluir a consulta | Investigar rede, DNS e destino |
| Erro em um nó do fluxo | Monitoramento comprometido | Acionar o responsável pela automação |
Escolha um grupo com poucos responsáveis e descreva quem assume cada serviço. O alerta precisa apontar a próxima ação, como abrir o painel de incidentes ou conferir o provedor. Para estruturar o diagnóstico, veja também como acompanhar erros e latência. Um canal movimentado sem responsáveis definidos raramente melhora a resposta a incidentes.
Crie o bot e valide a conversa de destino
No Telegram, abra o BotFather oficial e use o procedimento de criação de bot. A documentação de credenciais do n8n orienta a obtenção do token. Cadastre esse segredo em uma credencial Telegram dentro do n8n, em vez de escrevê-lo no texto da mensagem ou em uma planilha compartilhada.
Abra uma conversa com o bot e envie uma mensagem de início. Para um grupo, adicione o bot ao destino autorizado. Confirme que ele consegue enviar mensagens ali. No piloto, use uma conversa criada para testes, para que ninguém confunda uma simulação com uma indisponibilidade real.
Uma maneira visual de descobrir o identificador da conversa é criar temporariamente um Telegram Trigger, escutar um evento de teste e enviar uma mensagem ao bot. Inspecione o campo message.chat.id no evento recebido. Em grupos, envie um comando destinado ao bot se mensagens comuns não aparecerem. Não altere configurações de privacidade apenas para simplificar esse passo.
Use um bot exclusivo para o piloto: a Bot API estabelece condições para recebimento de atualizações por webhook ou consulta. Uma escuta de teste pode interferir em outra integração que usa o mesmo bot. Depois de obter o identificador, remova o trigger temporário do fluxo de monitoramento; o envio agendado não depende dele.
Adicione um nó Telegram com recurso Message e operação Send Message. Selecione a credencial, preencha Chat ID e envie uma frase simples, sem formatação especial. A referência do nó Telegram lista suas operações. Só avance depois de verificar a mensagem na conversa correta.
Monte a checagem HTTP com os nós visuais
Crie um fluxo com Schedule Trigger e configure o intervalo escolhido. Ajuste o fuso do workflow para a operação, por exemplo, America/Sao_Paulo. O guia do agendamento explica que o workflow precisa estar salvo e publicado para executar automaticamente. Os nomes de alguns controles podem variar conforme a versão instalada.
Depois adicione HTTP Request. Selecione GET e informe o endpoint aprovado pela equipe técnica. Caso exista autenticação, use uma credencial apropriada e com acesso mínimo. Não reutilize uma chave administrativa para consultar disponibilidade. Mantenha a validação de certificado habilitada, pois um problema de certificado também merece investigação.
- Em Options, adicione Response e habilite Include Response Headers and Status.
- Habilite Never Error para encaminhar respostas com status inesperado à sua condição visual.
- Configure Timeout com o tempo de espera inicial definido para o piloto.
- Execute o nó manualmente e inspecione a saída antes de criar as condições.
- Adicione um nó IF e selecione o campo de status pela interface.
- Compare com o código previsto no contrato e, quando necessário, confira também o conteúdo retornado.
A documentação do HTTP Request descreve essas opções. Never Error permite tratar códigos HTTP como dados, mas não transforma toda falha de transporte em uma resposta válida. Configure, nas opções de erro do nó, a continuação pela saída de erro disponível na sua versão e conecte esse caminho à classificação de “consulta não concluída”.
Se a resposta tiver um campo de saúde, arraste esse campo para uma segunda condição. Uma resposta com código esperado e conteúdo inconsistente deve reprovar a checagem. Não force o formato JSON quando o destino retorna texto. Primeiro observe o formato real e depois configure a comparação correspondente.
Use Edit Fields para criar os campos que seguirão pelo fluxo: nome do serviço, estado atual, horário e motivo resumido. Esses dados podem ser preenchidos por seleção visual e arraste. Não é preciso incluir um nó Code. Para entender como esse padrão se encaixa em outras rotinas, consulte automação com n8n em pequenas empresas.
Controle repetição, recuperação e falhas da automação
Enviar uma mensagem em toda execução malsucedida produz ruído. Crie uma Data Table com uma linha previamente cadastrada para cada serviço. Use colunas como serviço, estado anterior, último aviso e responsável. O nó Data Table permite consultar e atualizar dados entre execuções.
Depois da classificação, busque a linha pelo nome do serviço e compare o estado anterior com o atual usando IF. Se era saudável e passou a falhar, envie o alerta. Se continua falhando, mantenha o registro sem repetir a mensagem. Se voltou ao estado saudável, envie a recuperação. Na primeira configuração, use um estado inicial “desconhecido” e decida explicitamente como tratar a primeira observação.
Atualize o estado após a entrega bem-sucedida da mensagem quando houver transição. Caso o envio falhe, preserve a pendência para a próxima execução ou registre-a em uma coluna própria. Esse desenho simples não garante entrega exatamente uma vez: uma interrupção entre o envio e a gravação pode gerar duplicidade. Para poucos serviços, documentar essa limitação pode ser suficiente.
Evite sobreposição de execuções ajustando intervalo e duração do fluxo. Se houver concorrência, uma tabela sem coordenação pode permitir que duas execuções leiam o mesmo estado antigo e enviem o mesmo alerta. Antes de ampliar o monitoramento, valide serialização ou outra estratégia de coordenação compatível com sua instalação.
Escreva mensagens curtas: “API de pedidos: consulta não concluída; verificar painel operacional; responsável: suporte”. Inclua horário e ambiente. Não envie tokens, cabeçalhos completos ou o corpo de uma resposta que possa conter dados de clientes. Prefira links para painéis com autenticação.
Crie ainda um workflow separado iniciado por Error Trigger e selecione-o nas configurações de erro do principal, conforme o guia de tratamento de falhas. Ele cobre erros que realmente encerram a execução como falha. Erros tratados por uma saída alternativa precisam de sua própria notificação. Se a instância inteira parar, um fluxo interno não poderá avisar; use monitoramento independente para esse caso.
Antes de publicar, ensaie quatro situações controladas: resposta saudável, status inesperado, conexão indisponível e recuperação. Confira a conversa e o estado gravado depois de cada cenário. Para testar o Error Trigger, provoque uma falha controlada numa execução automática de teste; não presuma que executar manualmente o editor reproduz esse comportamento.
Exemplo: distribuidora de alimentos em Recife
Imagine uma pequena distribuidora em Recife cuja equipe comercial depende de uma API de pedidos. Este é um exemplo ilustrativo, sem resultados de um cliente real. A responsável técnica disponibiliza uma consulta de saúde que não cria pedidos nem consulta dados pessoais. O n8n verifica esse endereço e envia avisos ao grupo de suporte.
O texto do alerta distingue “API respondeu fora do esperado” de “não foi possível consultar”. Assim, o suporte sabe se começa pela aplicação ou pela conectividade. A equipe comercial recebe apenas uma orientação operacional confirmada pelo suporte, evitando que uma falha momentânea do monitor seja anunciada como queda de todo o sistema.
No ensaio, a técnica simula indisponibilidade em um ambiente separado. O grupo recebe a abertura, não recebe cópias a cada ciclo e recebe a recuperação quando a consulta volta a passar. Depois ela testa uma credencial inválida do bot para confirmar que a falha de entrega aparece no histórico e segue o caminho de escalonamento definido.
A aprovação depende desses comportamentos observados. A empresa não precisa adicionar IA para decidir se um código corresponde ao contrato. Se futuramente usar um modelo para resumir incidentes, preserve a classificação determinística e não permita que uma interpretação textual esconda uma falha objetiva.
Erros comuns
- Testar só o caminho saudável: simule falhas de resposta, transporte e envio.
- Tratar qualquer resposta como sucesso: confira o status e os campos relevantes.
- Ativar Never Error sem condições: a execução pode terminar normalmente mesmo quando o serviço falhou.
- Expor o token em mensagens: mantenha segredos nas credenciais e revise os dados registrados.
- Usar o mesmo servidor para tudo: uma queda conjunta pode derrubar serviço e monitor.
- Esquecer o retorno ao normal: a recuperação encerra a dúvida da equipe e deve ser testada.
Perguntas frequentes
Preciso programar para montar o fluxo?
O roteiro usa nós visuais, seleção de campos e condições. Você ainda precisa entender o contrato da API e conferir a saída de cada etapa. “Sem código” não elimina a necessidade de validar os dados e testar falhas.
O bot consegue monitorar o próprio n8n?
Um fluxo pode detectar erros de outros workflows enquanto a instância funciona. Ele não consegue enviar avisos se a própria instância estiver indisponível. Para cobrir esse cenário, mantenha uma checagem independente em outro ambiente.
Posso enviar alertas para um grupo?
Sim, desde que o bot esteja no destino adequado e tenha permissão para enviar mensagens. Valide o Chat ID com um teste controlado. Não use o nome visível do grupo como substituto automático do identificador esperado pelo nó.
Devo adicionar IA para analisar a disponibilidade?
Não é necessário para comparar status, validar campos e detectar transições. Regras claras tornam esse fluxo mais previsível. Uma análise textual posterior pode ajudar no resumo, mas não deve substituir as evidências da checagem.
