Uptime alto não é o mesmo que disponibilidade

"O site está no ar 99.99% do tempo" — quem nunca viu essa frase num pitch comercial? O número é bonito, dá conforto, vira badge no rodapé. Mas ele esconde mais do que mostra.

Uptime é uma medida, não uma garantia. E como toda medida, depende de como você define os limites.

O que "no ar" significa pro seu monitor

A maioria das ferramentas de monitoramento checa uma única coisa: um GET na home page. Se respondeu 200 OK dentro do timeout, está "up". Se não respondeu, está "down".

Isso pega:

• ✅ Servidor totalmente fora
• ✅ DNS quebrado
• ✅ Certificado SSL expirado
• ✅ Timeout completo

Mas não pega:

• ❌ Página inicial OK, checkout quebrado
• ❌ 200 OK retornando HTML de erro genérico ("Service Unavailable")
• ❌ Tempo de resposta degradado (lento mas no ar)
• ❌ API funcional, painel admin caído
• ❌ Cert SSL vence em 5 dias (ainda válido = "up")

Resultado: você fecha o mês com 99.99% no painel e fila de tickets reclamando.

Os três níveis de monitoramento

1. Disponibilidade básica (HTTP)

GET / e olhar status code. É o mínimo. Detecta a maioria dos problemas catastróficos mas perde os silenciosos.

Use pra: site institucional simples, landing page.

2. Keyword check

GET / e procurar uma palavra-chave no body. Se a palavra "Bem-vindo" sumiu, alguma coisa está errada — mesmo que o status seja 200.

Use pra: detectar página de erro genérica que serve 200, defacement, banner não programado.

3. Multi-endpoint

Monitora separadamente: home, login, API de pagamento, dashboard admin, webhook. Cada um tem alerta próprio. Status page mostra granularmente.

Use pra: SaaS, e-commerce, qualquer coisa onde diferentes partes podem falhar independentemente.

Frequência: 1 minuto vs 5 minutos

UptimeRobot grátis checa a cada 5 minutos. Sentinela e a maioria dos planos pagos checam a cada 1 minuto. Diferença na prática:

• Falha às 14:03:30, intervalo 5 min → detectada às 14:05 → alerta em ~14:06
• Falha às 14:03:30, intervalo 1 min → detectada às 14:04 → alerta em ~14:05

Parece pouco. Mas se você opera um e-commerce em horário de pico, 1 minuto de downtime não detectado é alguns pedidos perdidos. Multiplica por mês, vira diferença real.

A trade-off é custo: 1/min = 5x mais checks = mais carga no seu servidor (pequena) e mais carga no monitorador (paga isso no plano).

"Estamos no ar mas estamos lentos"

Latência degradada é o assassino silencioso. Site responde em 200 OK, mas levou 8 segundos. Usuário desistiu antes da resposta chegar. Pro monitor, ficou tudo OK.

Como pegar: monitore não só o status, mas o tempo de resposta. Métricas que importam:

• p50 (mediana): metade dos requests é mais rápido que isso
• p95: 95% dos requests é mais rápido que isso — o pior 5%
• p99: o pior 1%

Médio engana. Se p50 = 100ms mas p99 = 8s, sua experiência de usuário está com um problema sério mascarado pela média.

Janelas de manutenção: honest reporting

99.99% é honesto se você conta direito. Se você derruba a API toda quarta às 3h pra manutenção, isso conta como downtime — a menos que você tenha declarado a janela com antecedência.

Bom monitoring permite:

1. Criar janela de manutenção programada
2. Suprimir alertas durante a janela
3. Não contar o tempo da janela contra o uptime%
4. Mostrar banner "manutenção programada" na status page

Sem isso, ou você mente nos números ou paga em alarme falso.

A pergunta certa não é "qual meu uptime"

É: "quando alguma coisa quebrou nos últimos 90 dias, eu soube antes do cliente?"

Métrica honesta:

• Quantos incidentes abriram
• Tempo médio pra detecção (de quebra → primeiro alerta)
• Tempo médio pra resolução (de detecção → resolvido)
• Em quantos casos cliente avisou antes do monitor

Esse último é o teste real. Se você teve 3 incidentes esse mês e em 2 deles foi o cliente que reclamou primeiro, seu monitoring não tá fazendo o trabalho — independente do número agregado.

Conclusão prática

Antes de comemorar 99.9%:

1. Monitore mais que a home — adicione checkpoints pros fluxos críticos (checkout, login, API principal)
2. Use keyword check quando a aplicação serve 200 em modo degradado
3. Olhe p95 e p99 — não só status — pra pegar degradação
4. Declare janelas de manutenção pra ter uptime honesto
5. Acompanhe MTTD (tempo de detecção) — não só uptime

Uptime é um número fácil de divulgar. Disponibilidade real é mais difícil de medir — e mais importante de entregar.