99,9% de uptime não significa que o site de um cliente funcione

Um site de cliente com "99,9% de uptime" parece seguro. Esse número ainda permite 8,76 horas de queda por ano, ou cerca de 43 minutos em um mês de 30 dias. E ele só conta o tempo em que o servidor não respondeu de jeito nenhum.

A lacuna maior está no que uma verificação de uptime considera "ativo". Um site pode responder a todas as verificações e mesmo assim estar quebrado para quem o visita.

O que uma verificação de uptime realmente testa

Uma verificação HTTP básica faz uma única pergunta: o servidor responde com um código de status que significa sucesso? Ela olha o código de status e nada mais. Ela não lê a página.

Por isso, cada um destes casos passa como "ativo", desde que responda com um status de sucesso:

• uma página em branco causada por falha no cache, no tema ou no construtor de páginas
• uma página do provedor de hospedagem de "conta suspensa" ou "limite excedido"
• a página de um registrador depois que o registro do domínio venceu: quando um domínio do tipo .com vence, o registrador precisa fazer com que ele deixe de resolver para o seu site e pode mostrar uma página de renovação no lugar
• um redirecionamento para uma página que também está quebrada, se a verificação não seguir redirecionamentos
• um formulário de contato ou um checkout que carrega, mas falha quando alguém o envia

Também existe a lacuna entre as verificações. Com uma verificação a cada 5 minutos, uma queda de 3 minutos pode começar e terminar entre duas verificações e nunca aparecer no número de uptime.

Verifique o conteúdo, não só o código de status

Uma verificação de palavra-chave baixa a página e procura um trecho de texto. Ela funciona em duas direções:

• Falha quando o texto está ausente. Escolha um texto que só está lá quando a página realmente funciona. Uma resposta vazia, um aviso de suspensão ou a página de um registrador não vão contê-lo.
• Falha quando o texto aparece. Escolha um texto que só aparece quando algo está errado, como "Fatal error" ou "Database error".

Escolher o texto é a maior parte do trabalho:

• Use um texto que o servidor envia no HTML. Uma verificação de palavra-chave lê o código-fonte da página, não o que o JavaScript adiciona depois que a página carrega.
• Use um texto que o CMS gera a partir do conteúdo, como o título de uma seção ou o telefone no rodapé. Evite um texto que um template de erro estático também poderia conter, como o nome do site.
• Evite um texto que muda: preços, datas, o título do post mais recente.
• Verifique a URL final. Se example.com redireciona para https://www.example.com/, monitore a segunda.

Uma verificação de palavra-chave na página inicial e outra na página que dá dinheiro ao cliente (a página de reservas, uma categoria da loja, a página de contato) cobrem quase tudo o que um visitante notaria.

Lento não é fora do ar

Uma verificação de uptime dá ao servidor alguns segundos antes de registrar um timeout. Uma página que leva oito segundos para aparecer não está "fora do ar", mas para um visitante é quase a mesma coisa.

A lentidão aparece em dois lugares:

• O tempo de resposta de cada verificação. Uma tendência de alta depois de uma troca de hospedagem ou da atualização de um plugin é o primeiro sinal. Ele mede a rapidez com que o servidor responde, não quanto tempo a página leva para renderizar.
• Um teste de velocidade da página. O Lighthouse, que também está por trás do Google PageSpeed Insights, mede como a página carrega em um navegador. Uma verificação de uptime não consegue fazer isso.

Olhe os dois depois de cada atualização, não só quando o cliente reclamar.

Quando "fora do ar" não está fora do ar

O contrário também acontece. Alguns sites ficam atrás de uma proteção contra bots que pode responder a um serviço de monitoramento em um data center de forma diferente do navegador de um visitante. O monitor então informa que o site está fora do ar, enquanto ele abre normalmente para todo mundo.

Isso aconteceu com a gente no início de setembro de 2026: um monitor de um grande site público ficou como Fora do ar durante um incidente longo, enquanto a página carregava normalmente em um navegador e todas as verificações de outras regiões a davam como ativa. Antes de ligar para um cliente por causa de uma queda, abra o site você mesmo a partir de uma conexão normal.

O que nenhuma verificação de uptime cobre

Verificações de uptime e de palavra-chave carregam uma URL. Elas não fazem login, não preenchem formulários, não adicionam produtos ao carrinho nem pagam. O Baromio também não executa jornadas de várias etapas com scripts.

Para um cliente cuja receita depende de um fluxo assim, teste-o manualmente depois de cada atualização de plugin, tema ou pagamento: envie o formulário de contato para você mesmo, faça um pedido de teste, entre com uma conta de teste. Leva poucos minutos e pega o que uma verificação de URL não consegue.

Como configurar isso no Baromio

• Monitor HTTP: envia uma requisição HEAD (GET se o servidor recusar HEAD), considera ativo qualquer status abaixo de 400 e não segue redirecionamentos. Ele responde à pergunta "o servidor está respondendo?".
• Monitor de palavra-chave: busca a página com GET e procura o seu texto no código-fonte HTML, sem diferenciar maiúsculas de minúsculas. Você escolhe se a verificação falha quando o texto está ausente ou quando ele é encontrado. Informe a URL final, depois de qualquer redirecionamento.
• Tempo de Resposta: o tempo de resposta de cada verificação é armazenado, e a página do monitor mostra um gráfico das últimas 24 horas, 7 dias ou 30 dias. Não existe alerta de "mais lento que X milissegundos". Alertar após define quantas verificações com falha seguidas (1, 2, 3 ou 5) são necessárias antes de você receber um alerta, o que mantém instabilidades pontuais fora da sua caixa de entrada.
• Divergência Regional: enquanto um monitor HTTP ou de palavra-chave está fora do ar, o Baromio verifica o site de novo a partir de outros locais. Se todos o alcançarem, dois ciclos seguidos, o card do monitor mostra um selo CONTESTADO e a página do incidente explica o motivo. Isso nunca altera o alerta nem a recuperação; só avisa que o status Fora do ar pode ser um alarme falso. Está disponível em todos os planos.
• Velocidade da Página: ative Monitorar Velocidade da Página em um monitor HTTP ou de palavra-chave para executar o Lighthouse pelo Google PageSpeed Insights: 1 URL por semana no Free, 5 URLs por dia no Pro, 15 por dia no Business.
• Intervalos: a cada 5 minutos no Free (20 monitores), a cada minuto no Pro (9 EUR por mês, 30 monitores), a cada 30 segundos no Business (29 EUR por mês, 100 monitores).

Um checklist para cada site de cliente

1. Um monitor HTTP na página inicial.
2. Um monitor de palavra-chave na página mais importante, configurado para falhar quando um trecho de conteúdo real estiver ausente.
3. Uma olhada no gráfico de tempo de resposta depois de cada troca de hospedagem ou atualização maior.
4. Um teste manual de formulários, logins e checkout depois de cada atualização.
5. Antes de avisar o cliente sobre uma queda, abra o site você mesmo.

Fontes

• ICANN, Expired Registration Recovery Policy: após o vencimento, o registrador deve interromper o caminho de resolução DNS do domínio; uma página de destino exibida no lugar deve informar que o registro expirou.