Como Monitorar o Tempo de Atividade do Site: Um Guia Passo a Passo

A maioria das equipes descobre que seu site está fora do ar por um e-mail de cliente, uma postagem em rede social ou um painel de vendas que silenciosamente atinge um platô. Quando um humano percebe, a queda já está acontecendo há o tempo que alguém levou para reclamar, e o dano começou bem antes disso.

O monitoramento de uptime fecha essa lacuna com um mecanismo simples: verificações automatizadas disparadas no seu site em um cronograma, de fora da sua rede, que disparam um alerta no momento em que a resposta retorna errada ou não retorna. A configuração leva poucos minutos. Fazer com que ele diga a verdade exige um punhado de decisões que a maioria dos tutoriais ignora, porque um monitor deixado nos padrões permite falhas reais passarem e dispara falsos alertas.

Este guia percorre essas decisões em sete etapas: definir o que significa “up”, escolher tipos de verificação, definir frequência, verificar a partir de múltiplas localizações, configurar alertas, filtrar falsos positivos e relatar uptime contra um SLA.

Uma ideia une as sete etapas: trate o monitor como uma pilha de verdade, não uma única verificação. DNS prova que o nome resolve, TCP prova que o serviço está acessível, TLS prova que navegadores confiarão, HTTP prova que a aplicação responde, validação de conteúdo prova que a página certa foi carregada e monitoramento de jornada prova que um visitante pode completar a tarefa. Construa a pilha de fora para dentro, e todo alerta nomeia a camada que falhou em vez de simplesmente dizer “site fora do ar”.

Passo 1: Defina o Que “Up” Significa para o Seu Site

A definição mais preguiçosa de “up” é “o servidor responde”. É também a que causa problemas. Um host pode responder a ping enquanto o processo do servidor web está morto. Um servidor web pode retornar HTTP 200 enquanto serve uma página de manutenção, um template parcialmente renderizado ou conteúdo de outra pessoa após um sequestro de DNS. Nenhum desses conta como “up” para um visitante.

Ajuda nomear os três estados de down. Down duro: o host não responde nada. Down suave: o servidor retorna 200 enquanto serve erro de banco de dados, template vazio ou conteúdo de outra pessoa após um sequestro de DNS. Down fantasma: seus servidores estão saudáveis, mas uma borda CDN com problema ou falha regional no roteamento esconde o site de uma parte do público. Um monitor que só detecta down duro perde os dois estados que acontecem com mais frequência.

Então, antes de configurar qualquer coisa, anote o que precisa ser verdade para seu site estar genuinamente disponível:

• O domínio resolve para o endereço correto, rapidamente.
• Páginas críticas respondem com um código de sucesso. Críticas são a homepage e todas as páginas cuja falha custa dinheiro ou confiança: checkout, login, cadastro, endpoints chave de API.
• A resposta contém o conteúdo correto. Uma palavra-chave ou elemento que aparece apenas quando a página renderiza corretamente, assim um template de erro servido com 200 ainda falha na verificação.
• O certificado é válido e a resposta chega dentro de um tempo aceitável para um usuário.

Essa lista não é burocracia. Ela corresponde diretamente às camadas onde os pedidos realmente falham, e falhas ocorrem em DNS, TCP, TLS e HTTP de formas distintas. Uma verificação que testa apenas uma camada é cega para as outras três. A lista também determina quais URLs monitorar: não toda página do site, apenas as que estão na sua definição.

Escrito para um site de comércio eletrônico, o monitor da homepage pode ser: retorna 200 em até 3 segundos, contém “Frete grátis”, apresenta certificado com mais de 14 dias restantes, resolve pelo CNAME esperado para o CDN. O monitor de checkout é mais rigoroso: retorna 200, contém “Resumo do Pedido”, falha se o script do provedor de pagamento estiver ausente. Ambas as URLs contam como “up”. Mas não merecem a mesma definição.

Passo 2: Escolha Seus Tipos de Verificação de Uptime

Com a definição escrita, escolha verificações que confirmem cada parte dela. Cinco tipos de check cobrem quase todo cenário de uptime, e cada um pode enganar se for tratado como prova da experiência inteira:

Verificações HTTP e HTTPS

A verificação fundamental. Requisita uma URL, verifica o código de status e, se bem configurada, assegura que uma palavra-chave apareça no corpo da resposta. Qualquer coisa fora da faixa de sucesso, como os códigos 4xx e 5xx comuns, conta como falha. A asserção de conteúdo é o que diferencia “servidor respondeu” de “página realmente carregada”: um 200 com template de erro passa uma verificação ingênua e falha uma verificação por palavra-chave.

Verificações Ping (ICMP)

Monitoramento ICMP ping verifica se o host está alcançável e mede latência e perda de pacotes durante o percurso. É barato, rápido e útil para triagem em nível de rede. Também é fraco como única verificação, pois uma máquina pode responder ping com seu servidor web fora do ar, e algumas redes bloqueiam ou priorizam baixo o ICMP.

Verificações de Porta TCP

Uma verificação TCP confirma se uma porta específica aceita conexões: 443 para tráfego web, 25 para e-mail ou qualquer porta personalizada que seu app use. Detecta a falha clássica intermediária, onde o host está bem e o ping funciona, mas o processo do serviço travou e a porta recusa conexões.

Verificações DNS

Monitoramento DNS verifica que seu domínio resolve para os registros esperados e acompanha o tempo de resolução. Quando o DNS falha, por registro expirado, alteração errada ou queda do provedor, seu site fica fora do ar para todos mesmo que seus servidores estejam saudáveis. É a falha que as equipes mais esquecem de cobrir.

Verificações de Certificado SSL

Monitoramento de certificado SSL acompanha datas de expiração e problemas na cadeia de validação. Um certificado expirado é funcionalmente uma queda: navegadores intercedem com um aviso de tela cheia que a maioria dos visitantes não ultrapassa. Com lifetimes de certificado encurtando, apenas lembretes no calendário não bastam, então deixe o monitor contar os dias e alertar a 30, 14 e 7 dias.

Uma pilha inicial sensata: verificações HTTP(S) com asserções de conteúdo para cada página crítica, além de verificações DNS e de certificado no domínio, com ping e TCP onde ajudem a distinguir problemas de rede de problemas da aplicação.

Passo 3: Defina a Frequência Correta das Verificações

O intervalo da verificação é o teto para a velocidade de detecção. Uma queda que começa segundos depois de uma verificação bem-sucedida pode durar quase todo o intervalo até a próxima verificação que poderá detectá-la, e então verificação e alerta somam seu próprio tempo.

Coloque isso contra a meta de disponibilidade e o atraso fica caro. Uma meta mensal de 99,9% permite cerca de 43 minutos de indisponibilidade. Um intervalo de cinco minutos pode consumir mais de 10% desse orçamento antes de alguém saber do problema, o que faz parte do verdadeiro custo da indisponibilidade. Pense nisso como um orçamento de detecção: decida quanto do orçamento mensal você está disposto a gastar antes do primeiro humano saber. Permita 10% de um orçamento 99,9% e você tem cerca de 4 minutos, o que elimina o intervalo de cinco minutos antes mesmo de escalar a conversa. Em termos de receita, um site que gera $5.000 por hora perde mais de $400 em um ponto cego de cinco minutos. Como regra prática:

• A cada minuto para alvos críticos de receita: checkout, login, APIs de pagamento, qualquer coisa sob SLA formal.
• A cada 3 a 5 minutos para sites padrão de marketing e páginas de conteúdo.
• A cada 15 a 60 minutos para ferramentas internas, ambientes de staging e serviços de baixo risco.

Verificações HTTP leves são baratas o suficiente para executar em alta frequência em todos os lugares. Verificações baseadas em navegador mais pesadas rodam geralmente em intervalos mais lentos, sobrepostas a verificações básicas rápidas. Para um tratamento mais profundo de como frequência e localização interagem, veja este guia de frequência e locais do monitoramento.

Passo 4: Monitore a Partir de Múltiplas Localizações

Um único local de monitoramento dá um único ponto de vista, e isso gera dois modos de falha ao mesmo tempo. Você perde falhas que afetam apenas algumas regiões, como uma borda CDN ruim, mau funcionamento geo-DNS ou problema de roteamento entre um ISP e seu host. E você herda todo soluço da rede desse local como falso alarme.

Escolha locais que correspondam onde seus usuários estão. Um site que atende a América do Norte e Europa deve ser checado das duas costas dos EUA e pelo menos uma cidade europeia, não de um único data center de um país. Plataformas com rede global de monitoramento, Dotcom-Monitor entre elas, permitem selecionar pontos de verificação nos continentes para que o monitor veja o que seu público realmente vê.

Múltiplas localizações também desbloqueiam a verificação cruzada, da qual o passo 6 depende: quando um local reporta falha, a plataforma refaz verificações em outros locais antes de declarar o site em queda. E quando um incidente é real, o padrão geográfico é seu primeiro diagnóstico. Falha em todos os locais indica origem, DNS global, certificado ou deploy ruim. Falha em uma geografia indica borda CDN, roteamento regional ou provedor local. Passa HTTP em todos os lugares mas falha na asserção de conteúdo aponta para template errado ou página de erro em cache. Cada padrão é um chamado diferente para um fornecedor diferente, por isso entender o detalhamento por localização é importante antes de reiniciar qualquer servidor.

Passo 5: Configure Alertas e Escalação

Detecção só importa se a pessoa certa age sobre ela. Antes do primeiro incidente, decida quem ouve quais falhas, por qual canal e em qual ordem:

• Combine canal com severidade. Email serve para aviso de certificado expirando em 30 dias. Queda dura confirmada deve usar telefone, SMS ou a ferramenta de plantão que a equipe já monitora. Entrega de alertas pode ser por email, SMS, telefone e integrações com Slack, Teams e PagerDuty.
• Escale em caso de silêncio. O primeiro alerta vai ao engenheiro de plantão. Sem reconhecimento em um tempo definido, escala automaticamente para próximo nível. Um alerta que ninguém viu é um alerta que não aconteceu.
• Alerta sobre degradação, não só falhas totais. Uma triplicação no tempo de resposta costuma ser prelúdio a uma queda. Um limite de aviso na performance compra tempo que alerta binário de up/down não oferece.
• Silencie manutenção planejada. Janelas agendadas evitam que deploys disparem alertas, protegendo a credibilidade dos alertas que realmente disparam.

Escreva o alerta como um contrato: o que falhou, de onde, há quanto tempo e o que mudou desde a última verificação boa. “Check de conteúdo do checkout falhou em Frankfurt e Londres por duas execuções consecutivas; DNS e TLS passaram; ‘Resumo do Pedido’ esperado não encontrado; última vez OK 09:41 UTC” entrega ao responsável uma hipótese inicial. Um “site fora do ar” nu entrega um sirene.

Para um conjunto mais completo de regras sobre limites, roteamento e escalonamento, veja estas práticas de alertas de monitoramento de site.

Passo 6: Corte os Falsos Positivos

Falsos positivos são como programas de monitoramento morrem. Alguns alertas às 3 da manhã que não são nada e o engenheiro de plantão começa a dormir no seguinte que for real. A maioria dos falsos alarmes vem de quatro fontes: instabilidades momentâneas na rede entre checkpoint e site, timeouts ajustados mais apertados que o comportamento normal do site, problemas no próprio local de monitoramento, e deploys que ninguém avisou ao monitor.

Cada um tem um contramedida direta:

• Confirme de um segundo local antes de alertar. Uma falha deve disparar re-verificação imediata de outros checkpoints, não um alerta. No Dotcom-Monitor, um local que discorda dos outros provoca verificações em todos os locais selecionados, para que o dia ruim de um único checkpoint não alerte sozinho sua equipe.
• Configure timeouts por dados, não por esperança. Baseie limites nos tempos de resposta que seu site realmente apresenta, com margem, para que página lenta mas funcionando seja um aviso de performance e não uma queda fantasma.
• Valide conteúdo, não só conectividade. Asserções por palavra-chave cortam dos lados: pegam falhas suaves que código de status perde, e impedem o monitor de chamar a página de fora do ar quando só um widget de terceiros lento foi o problema, porque a verificação mira no que deve renderizar, não tudo que pode renderizar.
• Agende deploys no calendário. Janelas de manutenção são o conserto mais barato para falsos positivos.

Depois, classifique o ruído restante em três grupos numa revisão semanal: local ruim, limite ruim ou definição ruim de up. Local ruim recebe confirmação por múltiplas localidades. Limite ruim é reajustado pelos tempos de resposta reais do site. Definição ruim ganha asserção de conteúdo mais precisa. Um alerta que não se encaixa em nenhum desses permanece ruidoso até você entendê-lo, porque escondê-lo atrás de intervalo maior só atrasa o incidente real.

Passo 7: Meça o Uptime Contra Seu SLA

Cada resultado da checagem alimenta um registro permanente de disponibilidade, e esse registro é o que transforma monitoramento de detector de fumaça em evidência. Metas de uptime soam abstratas até que você as traduza em minutos:

A aritmética explica o conselho anterior de frequência: em quatro noves, um intervalo de verificação de cinco minutos pode perder mais tempo de inatividade que todo o orçamento mensal. Passe suas próprias metas por um calculador de disponibilidade para ver o que seu SLA realmente promete em minutos.

Mantenha o registro independente. Se seu host ou CDN tem SLA, sua reivindicação de créditos depende dos seus próprios dados medidos externamente, não na página de status do provedor. Mantenha essa evidência simples e exportável: timestamp, local do checkpoint, IP resolvido, resultado TLS, status HTTP, tempo de resposta e a asserção que falhou. Um screenshot de página de status é argumento; um histórico de verificações com local é evidência, seja para creditar ou para sua própria página pública de status. Relatórios de uptime e SLA agendados podem entregar esse registro automaticamente nas caixas dos stakeholders, detalhados por verificação e local. Esse detalhamento importa: uma média global saudável pode esconder uma região que ficou toda a terça-feira fora do ar.

Além do Uptime: Monitore Jornadas Completas do Usuário

Tudo o que vimos responde a uma pergunta: o site está alcançável e responde corretamente? Não diz se o visitante pode buscar no catálogo, adicionar ao carrinho, pagar ou entrar na conta, porque esses fluxos atravessam várias páginas, scripts e serviços terceiros que uma verificação de URL única nunca toca.

Para equipes de marketing, a jornada que vale a pena automatizar é aquela que suas campanhas prometem. Se o buscador pago envia visitantes para “Iniciar Teste Gratuito”, o script deve carregar a landing page, clicar no CTA, preencher o formulário com dados seguros de teste e confirmar o estado de agradecimento. Quando esse caminho quebra enquanto a campanha está ativa, uptime da homepage é métrica de vaidade.

Essa é a função do monitoramento sintético: sessões em navegador real e scriptadas que percorrem suas jornadas críticas passo a passo e indicam exatamente o passo que quebrou. Com um gravador como EveryStep, um fluxo de checkout ou login vira script monitorado repetível sem escrever código. Uma vez que as sete etapas aqui estejam sólidas, monitoramento a nível de transação é a camada natural seguinte.

Conclusão

Monitorar uptime de site bem é construir a pilha da verdade, não apenas marcar uma caixa. Defina up em termos de negócio e nomeie contra qual estado de down você está se defendendo. Cubra cada camada que um pedido atravessa com verificações HTTP, ping, TCP, DNS e certificado, e saiba onde cada uma pode enganar. Rode tudo dentro de um orçamento de detecção que seu SLA suporta. Verifique dos lugares onde seus usuários vivem. Escreva alertas com hipótese, escale em silêncio, confirme antes de alertar, e mantenha um registro independente e exportável do que sua disponibilidade realmente foi, por região e por verificação.

Configurado assim, um monitor de uptime deixa de ser uma caixa a marcar e vira o primeiro sistema a saber de um problema, minutos antes dos seus clientes. Essa vantagem é o ponto inteiro.

Perguntas Frequentes