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

Em resumo: Um código de status HTTP é um número de três dígitos com que o servidor responde a cada pedido. O grupo diz a categoria: 2xx = OK, 3xx = redirect, 4xx = erro de cliente, 5xx = erro de servidor. Da perspetiva da monitorização de uptime interessam-nos sobretudo as anomalias 5xx e 4xx.

Categorias de respostas

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

2xx: sucesso

200 OK - resposta OK standard. Este é o estado "healthy" para o qual monitorizas.

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

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 download resumible.

3xx: redirecionamento

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

302 Found / 307 Temporary Redirect - redirecionamento temporário. O Google não move o ranking. Usar 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). O 301 pode ser convertido a GET pelo cliente.

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 redirect (follow) ou considerar o redirect como 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 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 (não revelar a existência do recurso).

404 Not Found - a URL não existe. Não importa para a monitorização, importa para SEO (fuga de link equity).

405 Method Not Allowed - a URL existe mas não aceita o método dado (ex. POST para 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. Melhor que 404 para o Google (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 tipicamente adiciona o 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. 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 que o timeout. O backend normalmente ainda corre, só devagar.

520-525 Cloudflare errors - específico para 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 é mesmo manutenção planeada), 504, qualquer timeout
• Alerta em repetição: um 5xx pontual pode ser race condition; alerta se o mesmo endpoint cai 2× seguidas
• Seguir tendência ascendente: crescimento a longo prazo de 4xx pode significar broken link, scraper attack ou frontend partido
• Ignorar para alerting: 200-399 no intervalo esperado (seguir response time em vez do código)

Código de status + response time = 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. Response time máximo (tipicamente 5-10 segundos)
3. Keyword match no conteúdo (palavra-chave que tem de estar no HTML)
4. SSL válido + não antes do fim de validade

Falha de qualquer um = alerta.

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

O ePulz.io distingue código de status, response time, keyword match e estado SSL. Logs para cada verificação.

Experimentar durante 7 dias →