Códigos de status HTTP explicados: o que 200, 404, 502 significam para a monitorização

Categorias de respostas

• 1xx Informational - respostas transitórias, o cliente normalmente não as nota.
• 2xx Success - o pedido foi bem-sucedido. 200 OK é o valor por defeito.
• 3xx Redirection - o cliente deve ir para outro lado. 301 permanente, 302 temporário.
• 4xx Client errors - o cliente enviou algo incorreto. 404, 401, 403, 429.
• 5xx Server errors - o servidor falhou. 500, 502, 503, 504.

2xx: sucesso

200 OK - a resposta OK padrão. Este é o estado "healthy" que monitorizas.

201 Created - tipicamente a resposta a um POST que criou um novo recurso. Os clientes API esperam-na.

204 No Content - sucesso, mas o servidor não tem nada para devolver. Os endpoints DELETE usam-no frequentemente.

206 Partial Content - o servidor devolveu apenas uma parte (range request). Em streaming de vídeo ou downloads retomáveis.

3xx: redirecionamento

301 Moved Permanently - a URL mudou permanentemente. O Google transfere a SEO equity para a nova URL. Usa-o durante uma migração de domínio, uma transição de HTTP para HTTPS ou uma mudança para www/non-www.

302 Found / 307 Temporary Redirect - redirecionamento temporário. O Google não transfere o ranking. Usa-o para A/B testing, manutenção ou quando a URL voltar com o tempo.

308 Permanent Redirect - como 301, mas preserva o método HTTP (POST mantém-se POST). Com 301, o cliente pode converter o método em GET.

304 Not Modified - o cliente tem cache, o servidor confirma que o conteúdo não mudou. Poupa bandwidth.

Para a monitorização: Ao verificar respostas 3xx, configura se o monitor deve seguir o redirecionamento (follow) ou considerá-lo um erro. Alguns ataques DNS hijack manifestam-se como 302 inesperados.

4xx: erro do lado do cliente

400 Bad Request - erro sintático no pedido. Malformed JSON, header em falta, etc.

401 Unauthorized - credenciais em falta ou erradas. O cliente tem de se autenticar.

403 Forbidden - o cliente está autenticado mas não tem permissão. Atenção: alguns servidores devolvem 403 em vez de 401 por razões de segurança (para não revelar a existência do recurso).

404 Not Found - a URL não existe. Na monitorização de uptime de páginas vigiadas, um 404 é um alerta (a página desapareceu); 404 ocasionais de visitantes externos são antes um problema de SEO (fuga de link equity).

405 Method Not Allowed - a URL existe mas não aceita o método dado (ex. um POST para um endpoint que espera GET).

408 Request Timeout - o servidor esperou pelo pedido demasiado tempo e fechou a ligação.

409 Conflict - o pedido está em conflito com o estado atual (ex. update de uma versão que já não é atual).

410 Gone - o recurso foi removido permanentemente. Para o Google, melhor que 404 (um sinal para não tentar reindexar).

422 Unprocessable Entity - o pedido é sintaticamente OK mas contém dados semanticamente inválidos (failed validation).

429 Too Many Requests - rate limit. O cliente tem de abrandar. O servidor adiciona tipicamente um header Retry-After.

5xx: erro do lado do servidor

500 Internal Server Error - erro genérico. O backend lançou uma exceção que a aplicação não apanhou. Sempre alarme para a monitorização.

501 Not Implemented - o servidor não conhece o método HTTP (ex. um servidor antigo não suporta PATCH).

502 Bad Gateway - o reverse proxy (nginx, Cloudflare) não recebeu resposta do servidor backend. Tipicamente o backend caiu ou fez timeout.

503 Service Unavailable - o servidor está sobrecarregado ou em manutenção. Frequentemente com header Retry-After. Esta é uma resposta planeada, não um crash.

504 Gateway Timeout - o reverse proxy esperou pelo backend mais do que o timeout. O backend normalmente ainda corre, só responde devagar.

520-525 Cloudflare errors - específicos do Cloudflare. 520 = o backend devolveu algo ilegível, 522 = o backend não respondeu (connection timeout), 524 = o backend respondeu demasiado devagar (origin timeout).

Regras práticas para alerting

• Alerta imediato: 500, 502, 503 (se não for mesmo manutenção planeada), 504, qualquer timeout
• Alerta em repetição: um 5xx pontual pode ser uma race condition; alerta se o mesmo endpoint cair 2x seguidas
• Seguir a tendência ascendente: um crescimento a longo prazo de 4xx pode significar um broken link, um scraper attack ou um frontend partido
• Ignorar para alerting: 200-399 dentro do intervalo esperado (segue o tempo de resposta em vez do código)

Código de estado + tempo de resposta = a imagem completa

Seguir apenas o código de status não chega - o servidor pode devolver 200 mas em 30 segundos, o que da perspetiva do cliente é uma queda. A monitorização de qualidade combina:

1. Código de status esperado (tipicamente 200)
2. Tempo de resposta máximo (tipicamente 5-10 segundos)
3. Correspondência de palavra-chave no conteúdo (uma palavra-chave que tem de estar no HTML)
4. SSL válido e não perto do fim da validade

A falha de qualquer um deles = alerta.

Monitorização com classificação precisa de erros

O ePulz.io distingue o código de estado, o tempo de resposta, a correspondência de palavra-chave e o estado SSL. Há logs detalhados disponíveis para cada verificação.

Experimentar durante 7 dias →