200 OK: o que significa e o que esconde
200 OK significa que o servidor recebeu a requisição, entendeu ela e devolveu uma resposta bem-sucedida, mas não diz nada sobre se o conteúdo naquela resposta está correto. Um aviso de manutenção, uma página de erro e um template vazio podem todos ser servidos com um 200.
O que um 200 garante
Um 200 é o status de sucesso padrão. Ele diz um conjunto estreito e específico de coisas: o DNS resolveu, uma conexão TCP foi feita, o TLS negociou se a URL era HTTPS, o servidor aceitou a linha de requisição e os cabeçalhos, e produziu uma resposta que ele considera bem-sucedida. Para um GET, o corpo é o recurso solicitado; para um POST, é o resultado da ação.
O que um 200 não diz é se a página contém o catálogo de produtos, se o formulário de checkout renderizou, se o JavaScript que preenche a página recebeu os dados dele, ou se a resposta que você recebeu é a mesma que os seus visitantes em outro país estão recebendo. Tudo isso vive no corpo, e o código de status nunca olha o corpo.
O 200 que na verdade é uma falha
O monitoramento de código de status sozinho não é suficiente, porque um site quebrado responde 200 em todos esses casos:
- Uma página de manutenção. Servida deliberadamente com 200 por um script de implantação ou uma regra de CDN. O uptime parece perfeito durante toda a janela de indisponibilidade.
- Uma exceção de aplicação capturada. O framework captura o erro e renderiza uma página amigável de "algo deu errado" pelo pipeline normal de templates, que define o status padrão de 200.
- Um soft 404. Uma mensagem de "página não encontrada" devolvida com 200 em vez de 404. Os visitantes ficam confusos e os buscadores podem manter a URL indexada ou tratar o padrão inteiro como baixa qualidade.
- Uma casca vazia renderizada no cliente. O documento HTML carrega bem, mas a chamada de API que o preenche falhou. O status é 200 e a página está em branco.
- Uma cópia em cache desatualizada ou no idioma errado. Um nó de borda cuja busca na origem falhou continua servindo o que já tem, com 200.
- Um domínio estacionado ou sequestrado. Depois de uma mudança de DNS, ele responde 200 com o conteúdo de outra pessoa.
Um 200 lento ainda é um problema
O tempo de resposta muitas vezes importa mais do que o código. Uma página que leva doze segundos para devolver 200 está funcionalmente fora do ar para a maioria dos visitantes, que já terão saído antes de ela terminar. O código de status não tem nenhuma dimensão de tempo, então você tem que medir o tempo de resposta e definir um limite separadamente. O tamanho vale a pena observar pelo mesmo motivo: um 200 que devolve 300 bytes onde normalmente devolve 80 KB é um sinal forte de que a página renderizou sem o conteúdo dela.
Como verificar se um 200 é um sucesso real
- Leia a linha de status e o tempo juntos:
curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/ - Busque o corpo e faça uma asserção sobre um texto que só aparece quando a página está genuinamente funcionando, como um título, um preço ou um marcador de rodapé, em vez de algo que o template de erro também contém.
- Faça asserção sobre ausência também, não só presença. Buscar por frases como "em manutenção", "temporariamente indisponível" ou o texto de exceção do seu framework pega o caso da página de erro amigável.
- Compare o tamanho da resposta contra uma linha de base conhecida como boa. Um colapso repentino no comprimento do corpo geralmente significa que a casca renderizou e o conteúdo não.
- Verifique uma página profunda, não só a página inicial. Páginas iniciais são as mais fortemente cacheadas e as mais propensas a continuar respondendo 200 enquanto a aplicação por trás delas está quebrada.
- Repita a partir de mais de uma rede. Um 200 do seu escritório e um erro de outro continente aponta para DNS, CDN ou roteamento geográfico, não para a própria aplicação.
O que uma verificação de uptime verde pode perder
Um monitor que só lê o código de status vai reportar um site verde durante um incidente inteiro que começou com uma página de manutenção que ninguém removeu. Combinar a verificação de status com uma asserção de palavra-chave e um limite de tempo de resposta é o que transforma "o servidor respondeu" em "a página funcionou". A HostTracker oferece 13 tipos de monitor e alerta por e-mail, SMS, chamada de voz, Slack, Telegram e mais, então uma incompatibilidade de conteúdo dispara o mesmo alerta que uma indisponibilidade dispararia. Rode uma URL pela ferramenta de verificação HTTP para ver o status, os cabeçalhos e o tempo dela, ou leia a família 2xx e 500 Internal Server Error para as respostas que uma página de erro amigável está escondendo.