Códigos de estado HTTP explicados: qué significan 200, 404, 502 para el monitoring

En resumen: Un código de estado HTTP es un número de tres dígitos con el que el servidor responde a cada solicitud. El grupo dice la categoría: 2xx = OK, 3xx = redirect, 4xx = error de cliente, 5xx = error de servidor. Desde la perspectiva del monitoring de uptime nos interesan sobre todo las anomalías 5xx y 4xx.

Categorías de respuestas

• 1xx Informational - respuestas transitorias, el cliente normalmente no las nota.
• 2xx Success - la solicitud se realizó con éxito. 200 OK es el default.
• 3xx Redirection - el cliente debe ir a otro lugar. 301 permanente, 302 temporal.
• 4xx Client errors - el cliente envió algo malo. 404, 401, 403, 429.
• 5xx Server errors - el servidor falló. 500, 502, 503, 504.

2xx: éxito

200 OK - respuesta OK estándar. Este es el estado "healthy" para el que monitorizas.

201 Created - típicamente respuesta a un POST que creó un nuevo recurso. Los clientes API lo esperan.

204 No Content - éxito, pero el servidor no tiene nada que devolver. Los endpoints DELETE lo usan a menudo.

206 Partial Content - el servidor devolvió solo una parte (range request). En streaming de vídeo o descarga resumible.

3xx: redirección

301 Moved Permanently - la URL cambió permanentemente. Google transfiere SEO equity a la nueva URL. Usar durante migración de dominio, transición de HTTP a HTTPS, cambio a www/non-www.

302 Found / 307 Temporary Redirect - redirección temporal. Google no mueve el ranking. Usar para A/B testing, mantenimiento o cuando la URL volverá con el tiempo.

308 Permanent Redirect - como 301 pero preserva el método HTTP (POST sigue siendo POST). El 301 puede ser convertido a GET por el cliente.

304 Not Modified - el cliente tiene cache, el servidor confirma que el contenido no cambió. Ahorra bandwidth.

Para el monitoring: Al verificar respuestas 3xx configura si el monitor debe seguir la redirección (follow) o considerar la redirección como error. Algunos ataques DNS hijack se manifiestan como 302 inesperados.

4xx: error del lado del cliente

400 Bad Request - error sintáctico en la solicitud. Malformed JSON, header faltante, etc.

401 Unauthorized - credenciales faltantes o malas. El cliente debe autenticarse.

403 Forbidden - el cliente está autenticado pero no tiene permiso. Cuidado: algunos servidores devuelven 403 en lugar de 401 por razones de seguridad (no revelar la existencia del recurso).

404 Not Found - la URL no existe. No importa para el monitoring, pero sí para SEO (se escapa link equity).

405 Method Not Allowed - la URL existe pero no acepta el método dado (p.ej. POST a un endpoint que espera GET).

408 Request Timeout - el servidor esperó la solicitud demasiado tiempo y cerró la conexión.

409 Conflict - la solicitud está en conflicto con el estado actual (p.ej. update de una versión que ya no es actual).

410 Gone - el recurso fue eliminado permanentemente. Mejor que 404 para Google (señal de no intentar reindexar).

422 Unprocessable Entity - la solicitud está sintácticamente OK pero contiene datos semánticamente inválidos (failed validation).

429 Too Many Requests - rate limit. El cliente debe ralentizar. El servidor típicamente añade el header Retry-After.

5xx: error del lado del servidor

500 Internal Server Error - error genérico. El backend lanzó una excepción que la aplicación no capturó. Siempre alarma para el monitoring.

501 Not Implemented - el servidor no conoce el método HTTP (p.ej. un servidor viejo no soporta PATCH).

502 Bad Gateway - el reverse proxy (nginx, Cloudflare) no recibió respuesta del servidor backend. Típicamente el backend cayó o hizo timeout.

503 Service Unavailable - el servidor está sobrecargado o en mantenimiento. A menudo con header Retry-After. Esta es una respuesta planificada, no un crash.

504 Gateway Timeout - el reverse proxy esperó al backend más que el timeout. El backend normalmente sigue corriendo, solo lento.

520-525 Cloudflare errors - específico de Cloudflare. 520 = el backend devolvió algo ilegible, 522 = el backend no respondió (connection timeout), 524 = el backend respondió demasiado lento (origin timeout).

Reglas prácticas para alerting

• Alerta inmediata: 500, 502, 503 (si no es realmente mantenimiento planificado), 504, cualquier timeout
• Alerta al repetirse: un 5xx puntual puede ser race condition; alerta si el mismo endpoint cae 2× seguidas
• Seguir tendencia ascendente: crecimiento a largo plazo de 4xx puede significar broken link, scraper attack o frontend roto
• Ignorar para alerting: 200-399 dentro del rango esperado (seguir response time en lugar del código)

Código de estado + response time = imagen completa

Seguir solo el código de estado no basta - el servidor puede devolver 200 pero en 30 segundos, lo que desde la perspectiva del cliente es una caída. El monitoring de calidad combina:

1. Código de estado esperado (típicamente 200)
2. Response time máximo (típicamente 5-10 segundos)
3. Keyword match en el contenido (palabra clave que debe estar en el HTML)
4. SSL válido + no antes del fin de validez

Caída de cualquiera = alerta.

Monitoring con clasificación precisa de errores

ePulz.io distingue código de estado, response time, keyword match y estado SSL. Logs para cada control.

Probar durante 7 días →