Monitoramento de downtime vs. monitoramento de uptime
Eles rodam no mesmo mecanismo — um check agendado de fora da sua infraestrutura — mas o monitoramento de downtime enfatiza velocidade de detecção e qualidade do alerta. Uma ferramenta pode tecnicamente "monitorar uptime" e ainda fazer um trabalho ruim de downtime, se verifica raramente, alerta com ruído ou roteia alertas para um lugar que ninguém lê.
A pergunta prática não é "isso verifica meu site" — a maioria das ferramentas faz isso. É "quanto tempo passa entre meu site cair e uma pessoa descobrir" e "esse alerta chega a alguém que pode agir".
O que realmente causa downtime
A maioria das quedas vem de poucas causas: problema de DNS, certificado TLS expirado, domínio expirado, o host ou servidor falhando, ou um deploy ruim que quebrou algo sem lançar um erro limpo. Cada uma precisa de um check um pouco diferente para ser capturada com confiança — um ping simples de uptime pega um servidor morto, mas não um certificado que expira em três semanas.
Por isso monitoramento de downtime, bem feito, é um pequeno conjunto de checks em vez de um só: uptime, expiração de TLS, expiração de domínio e resolução DNS juntos cobrem as causas por trás da maioria das quedas reais.
Quão rápido é rápido o bastante
A resposta honesta é "mais rápido do que seus usuários percebem e reclamam". Um intervalo de 5 minutos significa um pior caso de 5 minutos entre o início da queda e o check percebê-la — razoável para a maioria dos sites, e o intervalo do plano gratuito da Holter. Qualquer coisa voltada a clientes e crítica para receita se beneficia de um intervalo menor e um período de tolerância mais curto antes do alerta.
Velocidade de detecção só importa se o alerta chega a alguém. Um monitor que dispara para um canal que ninguém acompanha, ou para uma caixa filtrada para uma pasta, adiciona sua própria latência — às vezes maior do que a queda em si.
Erros que atrasam a detecção
Verificar de um único local. Um ponto de vista só não distingue "o site caiu" de "este caminho de rede caiu" — verificar a partir de alguns locais de sonda descarta isso antes de disparar um alerta.
Alertar na primeira falha. Isso produz tantos falsos positivos que as pessoas começam a ignorar alertas, derrotando o propósito do monitoramento.
Não ter dono para o alerta. Um alerta que chega a algum lugar não monitorado é, na prática, igual a não ter alerta — a queda ainda é descoberta primeiro por um cliente.
Verificar só a homepage. Se checkout, login ou um caminho de API falhar sozinho, um check apenas da homepage não verá.
Downtime que nunca toca a homepage
Nem todo downtime parece um site morto. Um cron job que para, um worker de fila que morre silenciosamente ou um backup noturno que falha no meio podem seguir por dias sem que um único check externo falhe, porque nada na homepage mudou. Eles precisam de outro tipo de monitoramento: um heartbeat, em que o próprio job faz check-in quando tem sucesso (ou reporta falha explicitamente), e um alerta dispara quando um check-in esperado não chega na agenda.
Monitoramento de downtime que olha só a porta da frente perde essa categoria inteira. Um site pode parecer saudável para todo visitante enquanto um backup parou de funcionar por baixo — e o primeiro sinal de problema é descobrir, em uma emergência real, que não há backup recente para restaurar.
Depois do alerta: medir quanto tempo realmente levou
Detectar downtime rápido é só metade do trabalho — a outra metade é saber, depois, quanto tempo um incidente durou e quão rápido foi capturado. O histórico de incidentes de um monitor responde aos dois: quando o primeiro check falho aconteceu, quando o alerta disparou e quando tudo recuperou. Revisar isso depois de um incidente real é como um limite de falhas consecutivas ou intervalo de check é ajustado com o tempo, em vez de ser definido uma vez e esquecido.
Como a Holter faz isso
A Holter roda checks externos — uptime, TLS, DNS, expiração de domínio — a partir de vários locais de sonda, junto com monitores de heartbeat recebidos para crons, filas e backups que precisam fazer check-in em vez de responder a uma requisição. Um incidente abre quando um check falha além do seu limite de falhas consecutivas, ou quando um heartbeat esperado desaparece, alertando os canais configurados.
O plano gratuito cobre 5 monitores com checks a cada 5 minutos e sem cartão de crédito, suficiente para colocar detecção real de downtime — externa e por heartbeat — nas URLs centrais e jobs em segundo plano de um site hoje.
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.
Começar a pegar downtime cedo — grátis