Um proprietário de site normalmente descobre que seu site está fora do ar da mesma forma que os clientes: através de um e-mail de suporte, uma notificação de estorno ou uma queda no checkout que aparece no painel de análise na manhã seguinte. Nesse ponto, o incidente já tem horas e a receita foi perdida.
O monitoramento de disponibilidade do site é a prática de detectar quedas antes que isso aconteça. Mas “o site está no ar” acaba sendo uma pergunta mais difícil do que parece. Um site pode retornar um 200 OK enquanto o botão de checkout está quebrado. Um site pode ser acessível dos EUA e estar fora na Europa. Um site pode estar tecnicamente online e ainda assim falhar para os usuários porque o provedor de DNS está expirando o tempo de resposta ou o certificado SSL expirou às 2 da manhã.
Este guia cobre o lado operacional do monitoramento de disponibilidade do site: o que verificar, de onde verificar, com que frequência e o que fazer quando um alerta dispara. Ele é escrito para proprietários que gerenciam seus próprios sites, não para equipes SRE com um painel de controle dedicado. O objetivo é configurar um monitoramento em que você confie e depois ignorá-lo até que ele lhe envie uma notificação.
O Que “Disponível” Realmente Significa
Há uma lacuna entre “o servidor respondeu” e “um usuário pôde comprar algo.” O monitoramento de disponibilidade está exatamente nessa lacuna.
Uma verificação simples de monitoramento de uptime envia um ping para sua URL e busca um código de status 200. Esse é o básico. Ele captura falhas catastróficas (servidor fora, DNS quebrado, rede inacessível) e perde tudo que é mais sutil: um processador de pagamentos que retorna erro 500 no checkout, uma configuração de CDN que serve uma página em branco, um erro de JavaScript que quebra o botão de login no Safari.
O monitoramento real de disponibilidade sobrepõe várias verificações para que “o site está no ar” signifique que um usuário real, em um navegador real, em uma localização real, possa fazer o que veio fazer. O glossário da Dotcom-Monitor tem uma definição mais completa de disponibilidade de sites se você quiser a versão formal.
Um padrão comum de falha real: um deploy numa sexta à noite envia uma nova tag de analytics. O HTML ainda retorna 200 OK de todas as regiões, então uma ferramenta básica de uptime mostra tudo verde o fim de semana inteiro. Na manhã de segunda, o suporte está sobrecarregado de tickets porque a tag de terceiros bloqueia o manipulador de envio do formulário de checkout no Safari. Uma verificação em navegador real na página de checkout teria detectado a falha dentro de uma única janela de verificação. Uma checagem HTTP simples não conseguiria.
Por Que o Monitoramento de Disponibilidade é Importante
O custo da indisponibilidade varia muito dependendo do negócio, mas as categorias de dano são consistentes: transações perdidas, SLAs violados, reputação da marca prejudicada, penalidades no ranking de busca por rastreadores encontrando páginas de erro durante longas quedas, e o custo interno da resposta a incidentes com toda a equipe envolvida.
Para sites de e-commerce, mesmo alguns minutos de indisponibilidade durante o pico de tráfego podem significar milhares de dólares em pedidos perdidos. Para provedores SaaS, uma única queda sustentada pode gerar créditos de SLA e corroer a confiança do cliente construída ao longo dos anos. Para sites de mídia e publicação, a indisponibilidade durante um ciclo de notícias urgente representa tráfego que simplesmente nunca retorna.
O monitoramento de disponibilidade reduz o intervalo entre algo dar errado e alguém corrigir. Esse tempo médio para detecção (MTTD) é frequentemente a maior alavanca para reduzir o impacto total de um incidente.
Como Funciona o Monitoramento de Disponibilidade
A maior parte do monitoramento de disponibilidade depende de verificações sintéticas: requisições automatizadas enviadas por nós distribuídos globalmente. Essas verificações ocorrem em intervalos regulares — de alguns segundos até alguns minutos — e registram se o alvo respondeu corretamente dentro de um tempo aceitável.
Uma checagem típica envolve um agente em uma localização geográfica específica enviando uma requisição HTTP para sua URL e avaliando a resposta com base em um conjunto de regras. Retornou um código de status 2xx ou disparou um erro crítico no servidor? O tempo de resposta ficou abaixo do limite? A página continha o conteúdo esperado? Todos os recursos da página carregaram com sucesso?
Quando uma verificação falha, o sistema de monitoramento normalmente não dispara um alerta imediatamente. Em vez disso, ele costuma tentar novamente a partir do mesmo nó e, igualmente importante, a partir de diferentes nós. Isso filtra falhas de rede transitórias e problemas localizados no próprio nó de monitoramento, que poderiam causar falsos alarmes constantes. Somente quando as falhas são confirmadas em múltiplas localidades o sistema escala para um alerta.
Como Monitorar Uptime do Site: As Cinco Verificações que Todo Site Precisa
O conselho padrão é “monitorar uptime”. Isso perde a maior parte da superfície de falhas. A seguir, as cinco tipologias de verificações que capturam as falhas que proprietários de sites realmente vêem em produção.
1. Verificação de Status HTTP(S)
A verificação básica. Acesse uma URL, espere uma resposta 2xx, alerte em qualquer outra coisa. Configure para a homepage, a página de preços, a página de checkout e quaisquer landing pages ligadas a tráfego pago. Isso captura falhas graves e erros na negociação SSL.
Execute-a a partir de múltiplas localidades. Uma verificação de um único data center nos EUA pode mostrar “ativo” enquanto clientes em Sydney estão vendo erro CloudFront.
2. Verificação de Resolução DNS
Um site que não pode ser resolvido é um site que não existe, mesmo que o servidor esteja saudável. Problemas de DNS geralmente são causados por falhas de provedores (Route 53 teve algumas notáveis), domínios expirados ou problemas na propagação após mudança de registros.
Uma checagem de monitoramento DNS resolve seu domínio por vários resolvedores públicos e alerta quando a resposta muda inesperadamente ou a consulta falha completamente.
3. Validade do Certificado SSL
Certificados expiram. Podem ser revogados. Podem ser mal configurados durante uma renovação do Let’s Encrypt que falhou silenciosamente. Um visitante que recebe aviso de certificado expirado vai embora. Ele não clica em “Avançado > Prosseguir mesmo assim.”
O monitoramento de certificado SSL verifica a cadeia do certificado, data de expiração e status de revogação. Configure o alerta de expiração para disparar com 30 dias de antecedência, depois 14 e depois 7. Você quer tempo para rotacionar o certificado sem uma página de incidente.
4. Verificação Completa em Navegador Real
Uma resposta 200 não é a mesma coisa que uma página funcionando corretamente. Sites modernos dependem de pacotes JavaScript, scripts de terceiros (analytics, pagamento, chat) e ativos servidos via CDN. Qualquer um deles pode falhar enquanto o HTML ainda retorna 2xx.
Uma checagem real em navegador monitoramento de página web carrega a página do jeito que o Chrome faria, executa o JavaScript e verifica se os elementos DOM críticos aparecem. É esse o tipo de verificação que detecta os problemas de “a página parece quebrada” que checagens HTTP puras não pegam.
5. Verificação de Transação Crítica
Para um app SaaS, a verificação mais importante é “o usuário pode fazer login.” Para um site de e-commerce, é “o usuário pode completar o checkout.” São fluxos múltiplos que envolvem sessão, envio de formulário, chamada API e página final de confirmação.
O monitoramento sintético para transações executa um roteiro de jornada do usuário em horários pré-definidos (login, busca, adicionar ao carrinho, checkout) e alerta se alguma etapa falhar. A ferramenta EveryStep da Dotcom-Monitor permite que você grave esses fluxos em um navegador real sem escrever código.
Se for configurar apenas uma verificação além da HTTP básica, que seja essa. O monitoramento de transações é o sinal mais próximo da receita real.
Escolhendo Intervalos e Localizações para Monitoramento
De Onde Verificar
Um único local de monitoramento é um ponto único de falha para seu monitoramento. Se seu único nó estiver na Virgínia e a AWS us-east-1 tiver um problema regional, você terá um falso alerta de queda. Se seu nó estiver na Virgínia e a borda europeia da sua CDN estiver degradada, você perderá uma queda real.
A solução são verificações distribuídas em múltiplas geografias. A rede global de monitoramento da Dotcom-Monitor executa checagens em data centers na América do Norte, Europa, Ásia-Pacífico e América do Sul.
Para um site pequeno, três a cinco localidades são suficientes. Escolha uma perto de cada grande cluster de clientes, mais uma localizada fora para capturar problemas na rota de rede. Não pague por 30 localidades se seus clientes estiverem todos em um único país.
Uma regra prática: alerte quando pelo menos duas localidades reportarem falha dentro de uma janela de 30 a 60 segundos. Essa janela corresponde a dois ciclos consecutivos de verificação a cada 1 minuto, que filtra falhas transitórias em um único nó e ainda captura quedas reais rapidamente.
Com Que Frequência Verificar
A frequência de verificação equilibra custo e tempo de detecção. Os intervalos comuns:
- 1 minuto para páginas que geram receita (checkout, login, landing pages de tráfego pago).
- 5 minutos para páginas principais de marketing e monitoramento de API.
- 15 minutos para páginas secundárias, ferramentas internas e conteúdo de baixo tráfego.
Uma checagem a cada 5 minutos significa que uma queda pode durar até 5 minutos antes que você saiba dela. O custo dessa janela depende da receita que passa pela página afetada a cada minuto. A calculadora de disponibilidade da Dotcom-Monitor ajuda a dimensionar isso frente ao seu SLA.
Checagens a cada minuto custam mais (algumas ferramentas cobram por verificação, outras por monitor). Para a maioria dos sites pequenos, cobertura de 1 minuto nas três rotas de receita e 5 minutos nas demais é o ideal.
Roteamento de Alertas que Realmente Chamam Atenção
O modo de falha aqui é fadiga de alerta. Se seu monitoramento dispara alerta para cada pequeno problema, você começa a ignorar, e quando um problema real acontece, ele passa despercebido. Algumas regras práticas:
Configure uma política N-de-M. Não alerte para uma única falha. Alerta quando 2 de 3 (ou 3 de 5) checagens consecutivas falharem. Isso elimina a maioria dos falsos positivos sem atrasar alertas reais de forma significativa.
Separe críticos de não-críticos. O alerta de “checkout quebrado” deve acordar você às 3 da manhã. O alerta de “página de marketing lenta” pode ir para um canal de bate-papo em horário comercial. Configure rotas separadas para cada situação. O recurso de alertas da Dotcom-Monitor suporta canais por monitor, cadeias de escalonamento e regras para horários variados.
Use janelas de supressão durante manutenção planejada. Se for liberar uma atualização e espera uns 30 segundos de instabilidade, suprima os alertas nos monitores afetados durante a janela. Não os desative. A supressão deve expirar automaticamente.
Escalone após um atraso. Se o primeiro contato não reconhecer em 5 minutos, alerte o segundo. Após 15 minutos, alerte um terceiro. Tirar alguém de uma reunião é aceitável. Perder uma queda porque o primeiro respondente estava em um voo não é.
Adicione um dead man’s switch. Uma ferramenta de monitoramento que fica silenciosa não é o mesmo que um site saudável. Configure uma verificação heartbeat para alertar se nenhuma checagem retornar em 10 minutos. Isso detecta quando a própria plataforma de monitoramento está com problema.
Estratifique seus canais. Alertas críticos devem ir para telefone ou SMS, não e-mail. E-mail serve bem para resumos diários e relatórios de breaches de SLA de 99,95%. Um canal de Slack ruidoso para avisos moderados é aceitável. Uma ligação às 3 da manhã deve significar que algo realmente está errado.
O Que Fazer Quando um Alerta Dispara
Um alerta é o começo de um processo, não o fim. Escreva o que fazer para os três tipos de alerta mais comuns antes que eles aconteçam. O objetivo é eliminar decisões nos primeiros cinco minutos do incidente.
Um runbook mínimo para um alerta de “site fora do ar”:
- Abra o painel de monitoramento. Confirme a falha em pelo menos duas localidades antes de tratar como real.
- Verifique a última atualização. Se saiu alguma release nos últimos 30 minutos, faça rollback primeiro e investigue depois.
- Confira os provedores a montante: página de status do provedor DNS, página de status da CDN, página de status do provedor de hospedagem. A maioria das quedas é problema de terceiros.
- Se for problema de terceiros, publique em sua página de status e pare de tentar consertar do seu lado.
- Se for do seu lado, verifique os logs da aplicação para pico de erros, identifique o serviço falhando e reinicie ou faça rollback.
- Após resolver, faça um post-mortem de 15 minutos. Anote o que falhou, como percebeu, o que resolveu. Você não vai lembrar os detalhes em três meses.
Modos Comuns de Falha e Como Eles Se Apresentam
Um guia rápido para que o alerta não seja a primeira vez que você veja o sintoma.
Certificado SSL expirado. Todas as checagens HTTPS falham simultaneamente em todas as localidades. A checagem HTTP ainda funciona (porta 80) se você a servir. Corrija: rotacione o certificado. Previna: alertas de expiração de SSL em T-30, T-14 e T-7 dias.
Falha no provedor DNS. Algumas checagens falham, outras passam, sem padrão claro por região. O TTL determina quanto tempo a falha vai durar do ponto de vista do usuário. Corrija: mude de provedor ou aguarde. Previna: use um provedor DNS secundário no mesmo domínio.
Problema regional na CDN. Checagens de uma região falham enquanto outras passam. O carregamento da página retorna 5xx ou trava. Corrija: limpe o cache da CDN ou faça failover para a origem. Previna: monitore de múltiplas regiões para detectar isso em minutos, não horas.
Pacote JavaScript quebrado por deploy. Checagens HTTP passam (200 OK). Checagens em navegador real falham por falta de elementos DOM. Sintoma: clientes enviam e-mail “o botão não funciona.” Corrija: rollback. Previna: verificação em navegador real nas páginas críticas e bloqueio de deploy até checagem sintética aprovar.
Timeout de script de terceiros. A página carrega, mas lentamente. Checagens de transação falham intermitentemente na etapa que depende do script (widget de chat, analytics, A/B tester). Corrija: carregue o script assincronamente, defina timeouts, remova se não for essencial. Previna: alertas de tempo de carregamento em páginas críticas.
Como Escolher a Ferramenta Certa
O mercado tem dezenas de opções. UptimeRobot e Pingdom cobrem o uptime básico muito bem. StatusCake, Site24x7 e Uptrends competem por preço e variedade de recursos. Datadog Synthetics e New Relic Synthetics são indicados para times que já usam essas plataformas para APM.
As perguntas para fazer, em ordem:
- Ela roda verificações nas regiões onde meus clientes realmente estão?
- Suporta verificações em navegador real e transações multi-etapas, não só HTTP?
- O alerta integra com os canais que eu realmente monitoro (SMS, telefone, PagerDuty, Slack)?
- Oferece uma página pública de status para meus clientes?
- Qual o preço para verificações críticas a cada 1 minuto?
A Dotcom-Monitor cobre toda a pilha numa plataforma única: uptime, sintético, monitoramento de aplicações web, API, mais a camada de alerta e relatórios de uptime e SLA por cima. Veja preços para entender como fica a cobertura multi-checagem a 1 minuto para um site do seu tamanho.
O Que Fazer Esta Semana
Configure checagens HTTP(S) nas suas três páginas principais de receita a partir de pelo menos três locais geográficos com intervalos de 1 minuto. Adicione monitoramento de expiração SSL. Adicione uma verificação em navegador real na sua transação mais importante (login ou checkout). Configure alertas por SMS com política de falha 2 de 3. Anote o que fará se algum deles disparar.
