Como Funciona a Monitorização de Disponibilidade de Websites em 2026

Um serviço com 99,99% de disponibilidade está offline durante menos de 53 minutos por ano. Caindo para 99,9%, perde mais de oito horas. A monitorização de disponibilidade é a pequena peça de infraestrutura que apanha esses minutos no momento em que acontecem. Este guia explica como funciona, o que monitorizar, com que frequência verificar e os erros que transformam uma ferramenta útil em ruído de fundo.

O que um monitor de disponibilidade realmente faz

Um monitor de disponibilidade executa um pequeno ciclo. A partir de um servidor algures na internet pública, envia um pedido a um alvo que indica. Regista a resposta, o código de estado e a duração da ida e volta. Depois espera pelo intervalo escolhido e tenta novamente.

A sonda vive propositadamente fora da sua infraestrutura. Se monitorizasse a partir de dentro da sua própria rede, não detetaria as falhas que parecem normais por dentro mas que afetam os utilizadores reais. Esta é a diferença entre monitorização sintética (uma sonda externa) e monitorização de utilizadores reais (telemetria de visitantes reais). A maioria das equipas utiliza ambas. A monitorização de disponibilidade é o lado sintético.

O que pode efetivamente monitorizar

As ferramentas modernas de disponibilidade cobrem mais do que HTTP. Os nove tipos de sonda que encontrará no mercado respondem cada um a uma pergunta ligeiramente diferente.

• HTTP devolve um código de estado e um tempo de resposta para qualquer URL.
• Ping (ICMP) verifica se um host responde ao nível da rede.
• SSL verifica quantos dias restam no seu certificado.
• DNS confirma que os registos A, AAAA, MX, TXT ou NS continuam a resolver para os valores esperados.
• Porta TCP verifica se um serviço está à escuta numa determinada porta, ou se uma que devia estar fechada está subitamente aberta.
• WHOIS vigia a data de expiração do registo do seu nome de domínio.
• Blacklist verifica se o seu IP de envio foi parar à Spamhaus, SORBS ou listas semelhantes.
• Heartbeat inverte a relação: a sua tarefa faz ping ao monitor, e é alertado quando deixa de o fazer.

Com que frequência verificar

A frequência de verificação é um compromisso entre precisão e ruído. Uma cadência mais rápida apanha falhas mais curtas mas produz mais falsos positivos devido a oscilações transitórias da rede. Uma cadência mais lenta suaviza o ruído mas perde as falhas curtas que continuam a contar para o seu orçamento de erro.

Um padrão pragmático: 60 segundos para HTTP e ping em serviços importantes, 5 minutos para páginas de baixa prioridade, 15 minutos para SSL, de hora a hora para WHOIS. Desça para 30 segundos apenas para serviços onde a indisponibilidade lhe custa, comprovadamente, dinheiro por minuto. Ir abaixo dos 30 segundos raramente melhora o resultado e produz frequentemente fadiga de alertas.

Encaminhamento de alertas sem o ruído

Um alerta que ninguém lê é pior do que nenhum alerta. Três regras cobrem a maioria das equipas.

• Por predefinição, envie DOWN para um único canal, idealmente aquele que a sua equipa já consulta (Slack, Discord, Telegram ou e-mail).
• Use uma regra de limiar de pelo menos 3 falhas consecutivas antes de chamar alguém. Uma verificação falhada é ruído. Três seguidas são sinal.
• Encaminhe os serviços críticos para uma ferramenta de paging (PagerDuty, Opsgenie) através de um webhook assinado. Encaminhe tudo o resto para o chat. Confirme os incidentes para parar o pager assim que uma pessoa estiver a tratar do assunto.

Os erros que matam os programas de disponibilidade

O primeiro erro é monitorizar apenas a página inicial. Uma página inicial a funcionar diz-lhe quase nada sobre o fluxo de checkout ou sobre a API com que a sua aplicação móvel comunica. Adicione monitores HTTP específicos para os URLs que mais importam para a receita ou para a carga de suporte.

O segundo erro é a difusão silenciosa. Cada monitor dispara em cada canal, depois cada membro da equipa silencia os mais barulhentos, e o incidente verdadeiro aparece num canal silenciado. Defina uma rota predefinida, encaminhe as exceções para pessoas específicas e reveja as regras a cada trimestre.

Uma configuração inicial em 10 minutos

Se está a começar do zero, a sequência prática é curta. Crie um monitor HTTP no seu URL principal com um intervalo de 60 segundos. Crie um monitor SSL no mesmo hostname com uma janela de aviso de 30 dias. Crie uma regra de notificação que encaminhe DOWN para o chat da equipa. Adicione uma página de estado se tiver utilizadores externos que se preocupem com a disponibilidade. Adicione heartbeats para as tarefas cron que executam a faturação, os relatórios e os backups. Já está à frente do operador mediano.