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

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 valor por defecto.
• 3xx Redirection - el cliente debe ir a otro lugar. 301 permanente, 302 temporal.
• 4xx Client errors - el cliente envió algo incorrecto. 404, 401, 403, 429.
• 5xx Server errors - el servidor falló. 500, 502, 503, 504.

2xx: éxito

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

201 Created - típicamente la 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 descargas reanudables.

3xx: redirección

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

302 Found / 307 Temporary Redirect - redirección temporal. Google no traslada el ranking. Úsalo para A/B testing, mantenimiento o cuando la URL vaya a volver con el tiempo.

308 Permanent Redirect - como 301, pero preserva el método HTTP (POST sigue siendo POST). Con 301, el cliente puede convertir el método en GET.

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

Para el monitoring: Al verificar respuestas 3xx, configura si el monitor debe seguir la redirección (follow) o considerarla un 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 incorrectas. 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 (para no revelar que el recurso existe).

404 Not Found - la URL no existe. En el monitoring de uptime de páginas vigiladas, un 404 es una alerta (la página desapareció); los 404 ocasionales de visitantes externos son más bien un problema de SEO (se escapa la link equity).

405 Method Not Allowed - la URL existe pero no acepta el método dado (p. ej. un 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 (una señal de no intentar reindexarlo).

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

429 Too Many Requests - rate limit. El cliente debe ralentizar. El servidor añade típicamente un 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 responde lento.

520-525 Cloudflare errors - específicos 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 una race condition; alerta si el mismo endpoint cae 2x seguidas
• Vigilar la tendencia ascendente: un crecimiento a largo plazo de 4xx puede significar un broken link, una scraper attack o un frontend roto
• Ignorar para alerting: 200-399 dentro del rango esperado (sigue el tiempo de respuesta en lugar del código)

Código de estado + tiempo de respuesta = la 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. Tiempo de respuesta máximo (típicamente 5-10 segundos)
3. Coincidencia de palabra clave en el contenido (una palabra clave que debe estar en el HTML)
4. SSL válido y no cercano a la expiración

El fallo de cualquiera de ellos = alerta.

Monitoring con clasificación precisa de errores

ePulz.io distingue el código de estado, el tiempo de respuesta, la coincidencia de palabra clave y el estado SSL. Hay logs detallados disponibles para cada control.

Probar durante 7 días →