O que o check realmente faz
Um check básico de uptime envia uma requisição HTTP para uma URL escolhida — normalmente a homepage, às vezes uma página de login ou endpoint de saúde — e registra se recebeu resposta, qual status code voltou e quanto tempo levou. Um resultado saudável costuma ser um status 2xx dentro de uma janela aceitável, digamos alguns segundos.
Esse único check já captura as falhas mais comuns: o servidor não responde, dá timeout ou retorna uma página de erro (5xx) em vez do site. Ele não pega tudo — uma página que retorna 200 com conteúdo quebrado por dentro precisa de um check que também inspecione o corpo da resposta, não só o status code.
Escolhendo um intervalo de check
O intervalo é uma troca entre quão rápido você descobre um problema e quanto monitoramento realmente precisa. Um intervalo de 5 minutos significa que o pior caso é uma janela de 5 minutos entre o início de uma queda real e o check percebê-la — adequado para a maioria dos sites, incluindo qualquer coisa no plano gratuito da Holter, que verifica a cada 5 minutos sem cartão de crédito.
Intervalos menores importam mais conforme o custo de downtime sobe — um checkout ou API paga perdendo dinheiro a cada minuto fora do ar se beneficia de checks mais frequentes do que uma página de marketing. Ajuste o intervalo ao que alguns minutos de downtime não detectado realmente custariam, não ao que soa impressionante.
Evitando falsos alarmes
Uma única falha de check não é prova de queda — pode ser apenas um soluço transitório de rede entre a sonda e seu servidor. Alertar na primeira falha treina as pessoas a ignorar alertas, o que é pior do que não alertar.
A correção é uma regra de falhas consecutivas: só dispare um alerta depois de dois ou três checks seguidos falharem, idealmente vindos de mais de um local de sonda, para que um problema de rota em um caminho não seja confundido com seu site fora do ar. Isso transforma monitoramento de uptime de uma fonte barulhenta de falsos positivos em algo que as pessoas confiam e usam.
O que "no ar" deveria realmente significar
Um status code sozinho é uma definição fraca de "no ar". Um site que retorna 200 em 11 segundos está tecnicamente no ar e praticamente quebrado para qualquer pessoa que desistiu de esperar. Um limite de tempo de resposta, verificado separadamente do status passa/falha, captura o caso lento-mas-vivo que um check binário perde completamente.
Conteúdo também importa: uma resposta 200 com erro de banco impresso na página, ou uma página em branco onde deveria haver conteúdo, passa em um check ingênuo de status e falha para todo usuário real. Verificar conteúdo esperado na resposta — não só o código de resposta — fecha essa lacuna.
Por que mais de um local de sonda importa
Verificar de um único ponto de vista não só cria risco de um tipo de falso alarme — uma instabilidade de rota entre aquela sonda e seu servidor — como também perde quedas reais porém locais: um nó de borda de CDN falhando em uma parte do mundo, ou um resolvedor DNS usado só por alguns visitantes retornando uma resposta antiga. Um check que só pergunta "o site está no ar deste lugar?" não diferencia queda global de problema local.
Verificar de alguns locais de sonda diferentes captura os dois problemas de uma vez: descarta "é só este caminho" antes de alertar e pode revelar uma queda real para uma fatia relevante de visitantes mesmo que não seja global. Um único check saudável só significa que o site está no ar de onde você olhou.
Configurando um primeiro check
Comece pela URL que um visitante real acessa primeiro, defina o intervalo conforme quanto downtime não detectado você tolera, adicione um limite de tempo de resposta e exija ao menos duas falhas consecutivas antes de disparar um alerta. Depois verifique se o alerta realmente funciona — aponte o check para uma URL que você sabe que falhará e confirme que ele chega a um lugar onde alguém verá — antes de confiar nele de verdade.
O que monitoramento de uptime sozinho não pega
Um check de uptime passando significa que a URL observada respondeu corretamente — ele não diz nada sobre páginas que você não está verificando, jobs em segundo plano que param silenciosamente ou um certificado que vai expirar na semana que vem. Monitoramento de uptime é a base, não o quadro completo: combine com checks de TLS e expiração de domínio, e com monitoramento no estilo heartbeat para qualquer coisa que roda em agenda em vez de responder a uma requisição, como backups ou cron jobs.
Como a Holter faz isso
Os checks externos da Holter rodam a partir de vários locais de sonda na agenda que você define, e suportam limite de tempo de resposta junto do check passa/falha, para que um site lento seja sinalizado, não só um site morto. Alertas podem exigir falhas consecutivas antes de disparar, para que um soluço transitório isolado não chame ninguém.
O plano gratuito cobre 5 monitores com checks a cada 5 minutos e sem cartão de crédito — suficiente para colocar um check real de uptime, mais checks de TLS e expiração de domínio, na URL central de um site hoje, antes de decidir se você precisa de algo mais rápido ou elaborado.
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.
Configurar um check de uptime — grátis