Por que o uptime alerta mesmo com o site online?

Um alerta de uptime pode estar “certo” mesmo quando a página inicial carrega?

Sim. Uma aba do navegador mostrando a sua página inicial não prova que o endpoint monitorado passou na verificação da Astrina, e essa diferença é a primeira coisa a entender quando você se pergunta por que os alertas de uptime da Astrina disparam enquanto o site ainda está online. Em outras palavras, o alerta de uptime site online pode coexistir com uma experiência visual aparentemente normal. Uma pessoa pode abrir a página de marketing, ver um logotipo e assumir que está tudo bem. A Astrina pode estar verificando /status, /login ou uma resposta JSON em vez da página inicial.

Essa diferença importa. Uma página inicial pode carregar do cache enquanto o endpoint real expira no servidor. Um site também pode retornar um 200 para o esqueleto da página e ainda assim falhar na regra de conteúdo porque falta uma string obrigatória. Um detalhe pequeno, uma consequência grande.

Pense nisso como duas perguntas separadas. Uma é: “consigo ver alguma coisa?” A outra é: “a verificação exata passou?” Não são a mesma coisa, e entender a diferença entre página inicial e endpoint monitorado evita muita confusão.

Aqui vai um exemplo simples com 3 partes em movimento: o usuário carrega https://example.com, o monitor verifica https://example.com/api/health, e a API retorna um 500 por 90 segundos. Os visitantes podem nem notar se a página estiver em cache, mas a Astrina está certa em disparar porque o endpoint testado está quebrado. Isso não é contradição; é justamente o objetivo do monitoramento.

Qual parte da verificação está falhando de fato?

A forma mais rápida de ler um alerta de uptime é isolar a camada que falhou. DNS, TCP, TLS, HTTP, redirecionamentos e verificações do corpo falham por motivos diferentes, e cada um deixa um rastro diferente. Se você pular essa etapa, vai perder tempo culpando “o site” quando apenas uma camada escorregou, o que ajuda a entender por que o monitoramento dispara com site no ar.

Falha de DNS significa que a sonda não conseguiu localizar o host. Falha de TCP significa que o host foi encontrado, mas a conexão não conseguiu abrir. Falha de TLS ou SSL significa que o certificado, o hostname ou o handshake não satisfizeram a sonda. Falha de HTTP significa que o servidor respondeu, mas com o código de status errado. Falha em redirecionamento significa que a cadeia foi para um lugar inesperado ou excedeu um limite. Falha na correspondência de conteúdo significa que a página carregou, mas o corpo não continha o texto esperado.

Essas categorias são concretas, não cosméticas. Um redirecionamento 301 para uma página de login pode ainda parecer “online” para uma pessoa, mas o monitor pode falhar se estiver esperando um 200 no caminho original. Um certificado que expira em 2 dias pode gerar aviso em alguns navegadores e não em outros, enquanto a Astrina já pode sinalizar o estado de TLS. Esse é o tipo de diferença que vira um alerta confuso às 09:17.

Se a sua verificação mira um endpoint privado, a falha pode ser ainda mais específica. Um endpoint pode retornar 200 enquanto outro retorna 403 por causa de uma regra de autenticação adicionada na semana passada. O site está no ar, mas o caminho não está.

Por que usuários e monitores veem resultados diferentes ao mesmo tempo?

Usuários e monitores não veem a web do mesmo lugar. Um navegador pode se beneficiar de cache local, de uma sessão ativa ou de um nó de CDN rápido perto do visitante. A sonda da Astrina pode atingir outra região, outro caminho de IP ou uma requisição fria, sem estado de navegador nenhum.

Essa diferença explica muita coisa. Um visitante em Londres carrega o site em 1 segundo. Outra sonda, em um local diferente, vê um timeout em 5 segundos porque um caminho de trânsito está congestionado. Os dois relatos podem ser verdadeiros ao mesmo tempo.

O comportamento da CDN é uma causa comum. Se a borda entrega a página inicial, mas não um asset aninhado, a página ainda pode parecer “certa” a olho nu. Um esqueleto em cache pode esconder a origem quebrada. O monitor, porém, pode estar verificando o caminho da origem diretamente ou uma rota que a CDN não mantém em cache por muito tempo.

Diferenças geográficas também podem importar. Um firewall pode permitir tráfego do IP do seu escritório e bloquear um intervalo de IPs da sonda. Um problema de roteamento pode afetar um continente por 12 minutos e deixar o restante intocado. Esse tipo de visão dividida é irritante, mas é real. Nenhuma tentativa de relativizar muda o caminho dos pacotes.

Às vezes o resultado é ainda mais simples: o navegador tenta novamente automaticamente, enquanto o monitor não. Uma página que finalmente carrega depois de 3 tentativas ainda pode disparar um alerta se a verificação expirar na primeira tentativa. Isso não significa que a Astrina seja “exigente demais”. Significa que o serviço está flertando com a falha.

Uma indisponibilidade parcial pode disparar um alerta mesmo que o site principal funcione?

Sim, e esse é um dos padrões mais comuns. O site público pode continuar acessível enquanto uma dependência quebra nos bastidores. Uma API de checkout, um serviço de imagens ou um backend de busca podem falhar sem derrubar a página inicial.

Considere um site de e-commerce com 4 camadas: a página inicial, a API de produtos, o gateway de pagamento e o serviço de estoque. Se a página inicial estiver em cache, mas a API de produtos retornar resultados vazios, o visitante ainda pode cair na página e ver um banner. A Astrina pode verificar o endpoint da API e disparar imediatamente. O site está “no ar” no sentido casual, mas uma função essencial está fora.

Um único asset quebrado também pode importar. Se o seu monitor verifica se a imagem principal ou um bundle JavaScript está presente, um arquivo ausente pode falhar na checagem de conteúdo mesmo que o HTML carregue. Um arquivo faltando pode ser suficiente. Isso não é dramático; é a realidade operacional.

Falhas específicas por região criam um problema parecido. Suponha que um data center atenda usuários em um país, enquanto outra região está degradada. O site principal pode carregar pela região saudável, mas requisições da região quebrada podem expirar ou retornar erros. O alerta não está errado. Ele está dizendo que a disponibilidade é desigual.

Existe também um caso mais sutil: uma dependência lenta pode empurrar a resposta além do limite da verificação. Uma página pode renderizar depois de 8 segundos, mas se o limite do monitor for 5 segundos, a Astrina vai disparar. Isso é útil. Lentidão costuma ser o primeiro passo antes da queda.

Quais detalhes da resposta você deve inspecionar primeiro?

Comece pelos campos que dizem o que falhou, não o que você espera que tenha falhado. Os primeiros itens a inspecionar são código de status, tempo de resposta, correspondência do corpo, estado do certificado e cadeia de redirecionamento. Se o alerta incluir a localização da sonda, leia isso também, porque a localização pode explicar um problema específico de rota.

Leia esses campos nessa ordem. Um 500 é um problema diferente de um 200 com o corpo errado. Um timeout é diferente de novo. Se você vir uma cadeia de redirecionamento com 4 saltos, pergunte se o monitor deveria seguir todos os 4 ou se deveria observar um endpoint mais simples. Quanto mais saltos, mais lugares para falhar.

A localização da sonda merece uma segunda olhada. Um resultado de Frankfurt pode ser diferente de um de Singapura se um nó de CDN ou uma rota upstream estiver instável. Esse detalhe muitas vezes explica por que um operador vê uma indisponibilidade enquanto outro não vê nada. Os dois operadores estão dizendo a verdade do lado deles.

Se o seu alerta incluir cabeçalhos, fique atento aos relacionados a cache. Uma resposta servida do cache pode esconder uma falha de origem por um tempo. Uma resposta marcada como “stale” ou “miss” pode revelar a condição real. Pequenas pistas importam.

Quando isso provavelmente é falso positivo e quando é um problema real de disponibilidade?

Um falso positivo costuma ser estreito e repetível de uma forma pequena. Um problema real de disponibilidade geralmente afeta mais de uma verificação ou fica mais fácil de reproduzir. Essa distinção economiza tempo. E também evita que você tente “consertar” o monitor quando o problema é o serviço.

Procure primeiro por uma dependência instável. Se o alerta aparece uma vez, some e não volta nos 30 minutos seguintes, um problema transitório no upstream é possível. Se ele dispara a cada 2 minutos no mesmo endpoint, a verificação pode estar rígida demais ou o serviço pode realmente estar instável. Padrões importam mais do que histórias.

Uma verificação rígida demais costuma parecer assim: a página renderiza, mas uma asserção de conteúdo espera uma frase exata que mudou no release da semana passada. A equipe de produto trocou “Entrar” por “Fazer login”, e o monitor passou a falhar por mismatch no corpo. O site está online. A verificação está desatualizada.

Por outro lado, um problema genuíno costuma mostrar sinais em mais de um lugar. A página inicial carrega devagar, a API retorna 503 e o certificado está perto de expirar. Isso não é uma estranheza isolada. É uma pilha de pequenos avisos apontando na mesma direção.

Existe também o caso “depende de quem você pergunta”. Usuários atrás de uma VPN corporativa podem pegar um caminho estável, enquanto a sonda pega um caminho quebrado. Isso pode parecer um falso positivo no começo, mas normalmente é um problema real de alcançabilidade para pelo menos um público. Um site que está no ar para 80% dos visitantes não está totalmente no ar.

O que você deve mudar se o site está “no ar”, mas a Astrina continua disparando?

Faça com que o alvo monitorado corresponda ao que você realmente se importa em acompanhar. Se a página inicial está bem, mas a API é o que importa, monitore a API. Se a página inicial é ruidosa demais, mova a verificação para um endpoint de saúde mais limpo. Essa única mudança pode remover muito ruído.

Depois, restrinja ou relaxe a regra de conteúdo apenas quando a regra for o problema. Uma verificação de uma frase específica é útil se a frase for estável. Ela é menos útil se o texto muda a cada release ou por causa de localização. Se você mantiver uma checagem de corpo, escolha uma string que seja improvável de mudar em uma atualização menor de conteúdo.

Você também deve revisar o caminho de redirecionamento. Um 302 para uma tela de login pode ser aceitável para usuários, mas não para um monitor. Nesse caso, monitore o endpoint que representa a saúde do serviço em vez da rota pública. Isso é uma decisão de configuração, não filosófica.

Se o problema for tempo, configure o caminho monitorado para algo mais leve. Uma página inicial completa com 12 assets é um sinal ruim de saúde se tudo o que você precisa é uma resposta rápida. Um endpoint mais leve fornece uma resposta melhor e menos alarmes falsos. Verificações rápidas envelhecem melhor do que as “sofisticadas”.

Se você ainda estiver configurando o monitor, o caminho de instalação do agente está aqui: * and the normalized visible-text size. Se você também precisar acompanhar a configuração relacionada no analytics, veja como adicionar astrina ao google. E, se você gerencia várias propriedades, o artigo sobre astrina para clientes de agência com múltiplos sites é um próximo passo útil.

Uma última checagem: compare o que o alerta diz com a URL exata, não com o nome da marca. Se o alerta está disparando em /api/health e a página inicial está no ar, isso é o comportamento esperado. Se o alerta está disparando na página inicial em si, então o problema merece uma análise mais profunda, porque uma página inicial que entrega conteúdo, mas falha em verificações de conteúdo, TLS ou roteamento, ainda é um incidente real para a Astrina.