O que deve disparar um alerta de queda
Comece por falhas que visitantes sentiriam diretamente: a homepage não responde, o caminho de login ou checkout retorna erro, o endpoint de API de que outro sistema depende falha, DNS não resolve mais, ou o certificado TLS é inválido ou está perto o suficiente da expiração para exigir ação.
Evite alertar em cada requisição isolada que falha. Um único soluço de rede vindo de um local de sonda pode ser ruído. Para a maioria dos sites, uma regra melhor é exigir duas ou três falhas consecutivas, de preferência confirmadas por mais de um local de sonda, antes de abrir um incidente.
Quem deve receber o alerta primeiro
Roteie o primeiro alerta para quem consegue começar a correção de fato: o fundador, o freelancer responsável pela manutenção, o canal de suporte da agência ou o engenheiro de plantão. Uma caixa compartilhada ou canal do Slack funciona só se alguém é responsável por acompanhá-lo.
Se ninguém é dono do destino, o alerta não existe na prática. O site ainda será descoberto por um cliente primeiro; a ferramenta de monitoramento só cria um registro com data e hora que ninguém viu.
Uma linha do tempo prática de retry e escalonamento
Para um site normal voltado a clientes, verifique a cada 5 minutos, exija um pequeno limite de falhas consecutivas e alerte assim que esse limite for cruzado. Isso captura downtime real dentro de uma janela previsível sem chamar alguém para cada falha transitória de rede.
O escalonamento deve acompanhar o risco do negócio. Um site institucional talvez notifique primeiro por email. Um checkout, API paga ou site de cliente em contrato de manutenção deve ir para um canal mais rápido como Slack, Discord ou webhook para o sistema que a equipe já acompanha.
Texto de alerta que acelera a resposta
Um alerta útil diz o que falhou, de onde foi verificado, quando começou e o que o monitor esperava ver. "Homepage retornou 500 em dois checks consecutivos" é acionável. "Problema no site detectado" não é.
Inclua contexto suficiente para pular a primeira rodada de adivinhação: URL, status code, tempo de resposta, falha de TLS ou DNS e link para o histórico do incidente. Durante uma queda, clareza importa mais que criatividade.
Como reduzir falsos positivos
Use falhas consecutivas, locais de sonda e limites sensatos de tempo de resposta. Não configure alerta de tempo de resposta tão baixo que variação normal vire incidente. Não monitore uma página que deve bloquear bots, exigir sessão ou variar muito por visitante, a menos que você tenha uma afirmação clara do que significa "saudável".
Revise os primeiros incidentes. Se todo alerta é ruído, ajuste limites antes que as pessoas aprendam a silenciar o canal. Se os alertas chegam depois dos clientes reclamarem, reduza o intervalo ou roteie para um lugar mais visível.
Como a Holter lida com alertas de queda
A Holter acompanha URLs, TLS, DNS, expiração de domínio e check-ins de heartbeat de fora da sua infraestrutura. Você escolhe o canal de alerta e o limite de falhas, então um incidente real só abre depois que o monitor tem evidência suficiente para merecer sua atenção.
O plano gratuito cobre 5 monitores com checks a cada 5 minutos e sem cartão de crédito, suficiente para colocar alertas confiáveis de queda em um site real: homepage, login ou API, TLS, domínio e um heartbeat para o job em segundo plano que usuários nunca veem.
O Holter monitora isso por você: verificações externas e heartbeats para falhas silenciosas. Plano grátis: 5 monitores, verificações a cada 5 minutos, sem cartão.
Criar um alerta de queda confiável — grátis