Siempre que un navegador, una aplicación o una herramienta de monitorización pide algo a un servidor web, el servidor empieza su respuesta con un código de estado. Es un número breve que resume el resultado: ha funcionado, ve a otro sitio, has hecho algo mal o ha fallado el servidor.

El primer dígito indica la clase, y la clase suele bastar para entender la situación.

Las cinco clases

Clase Nombre Significado
1xx Informativa La petición se ha recibido y el procesamiento continúa. Rara vez es visible para los usuarios.
2xx Éxito La petición se ha recibido, entendido y aceptado.
3xx Redirección El cliente debe dar otro paso, normalmente solicitar una dirección distinta.
4xx Error del cliente La petición es incorrecta o no está permitida. El problema está del lado de quien la hace.
5xx Error del servidor La petición parecía válida, pero el servidor no pudo completarla.

«Error del cliente» no significa que el visitante tenga la culpa. Un enlace roto en tu propio sitio produce un 404, y sigue siendo un problema de tu sitio que te toca arreglar.

1xx: informativos

Son respuestas provisionales. 100 Continue y 101 Switching Protocols son ejemplos. Las comprobaciones de páginas corrientes casi nunca se las encuentran, porque la respuesta final llega después.

2xx: éxito

  • 200 OK. La petición se ha completado y la respuesta contiene el contenido. Es el resultado normal de una página que funciona.
  • 204 No Content. La petición se ha completado y no hay nada que devolver. Habitual en las API.

3xx: redirecciones

Una redirección le dice al cliente que pregunte en otro sitio. La nueva dirección llega en la cabecera Location.

  • 301 Moved Permanently. La dirección ha cambiado para siempre. Se espera que los navegadores y los buscadores usen la nueva. Uso típico: mover un sitio a un dominio nuevo o forzar https.
  • 302 Found. Un cambio temporal. Los clientes deben seguir usando en el futuro la dirección original.
  • 304 Not Modified. No es un cambio de dirección: el contenido no ha cambiado, así que el cliente puede usar su copia en caché.

Hay otro par que conviene conocer. 308 y 307 se comportan como 301 y 302, pero garantizan que el método y el cuerpo de la petición se mantienen, lo que importa para formularios y API.

Cada redirección cuesta un viaje de ida y vuelta adicional, y una cadena de redirecciones (de A a B y a C) añade uno por paso. Un bucle de redirecciones, en el que el destino lleva de vuelta al principio, nunca llega a una página, y los navegadores acaban deteniéndose con un error.

4xx: errores del cliente

  • 401 Unauthorized. La petición no incluye credenciales válidas. A pesar del nombre, significa «no autenticado»: inicia sesión o envía credenciales válidas e inténtalo de nuevo.
  • 403 Forbidden. El servidor ha entendido la petición y la rechaza. Puede que el cliente sea conocido pero no tenga permiso, y volver a iniciar sesión no lo cambiará.
  • 404 Not Found. No hay nada en esta dirección. Un servidor también puede devolver 404 para ocultar una página a quienes no tienen permiso para verla.
  • 429 Too Many Requests. El cliente ha enviado demasiadas peticiones en un tiempo determinado. La respuesta puede incluir una cabecera Retry-After que indica cuánto esperar.

5xx: errores del servidor

  • 500 Internal Server Error. Un fallo general. El servidor se ha topado con algo que no sabía gestionar, a menudo un error de programación o una mala configuración.
  • 502 Bad Gateway. Un servidor que actúa como puerta de enlace o proxy ha recibido una respuesta no válida del servidor que tiene detrás.
  • 503 Service Unavailable. El servidor no puede atender la petición ahora mismo, por ejemplo por mantenimiento o sobrecarga. Está pensado para situaciones temporales y puede incluir una cabecera Retry-After.
  • 504 Gateway Timeout. Una puerta de enlace o un proxy ha esperado demasiado al servidor que tiene detrás.

Para interpretar caídas, 502, 503 y 504 suelen indicar un problema entre capas: el proxy de delante funciona, y aquello a lo que reenvía no.

Por qué importan los códigos de estado en la monitorización

Un código de estado es la forma más rápida de comprobar que un sitio responde y responde bien. Separa problemas distintos que a un visitante le parecen iguales:

  • Ningún código (tiempo de espera agotado, conexión rechazada, error de DNS): no se pudo alcanzar el servidor.
  • 5xx: se alcanzó el servidor y falló.
  • 4xx en una página que debería funcionar: una página que falta, un problema de permisos o un bloqueo contra quien hace la petición.
  • 3xx donde esperabas 200: una redirección que puede haberse añadido, eliminado o roto.

Seguir los códigos a lo largo del tiempo también revela patrones. Un solo 503 durante un despliegue no es lo mismo que un 503 todas las noches a la misma hora.

Redirecciones en la monitorización

Una comprobación que solicita una dirección necesita una regla para las redirecciones. Tratar un 301 como un fallo haría que cualquier sitio que redirige http a https, o example.com a www.example.com, pareciera roto. Por eso la mayoría de las herramientas siguen las redirecciones y juzgan la respuesta final, con un límite de saltos para que un bucle no pueda seguir eternamente.

Cómo juzga UptimeWire una respuesta

UptimeWire envía una petición GET a la dirección que has configurado y sigue las redirecciones, hasta cinco. Después mira la respuesta final:

  • De 200 a 399 cuenta como disponible. Eso incluye los códigos de éxito 2xx y las respuestas 3xx en las que no avanza más.
  • Todo lo demás es un fallo. Eso incluye 404, 429, 500, 502, 503 y 504.
  • 401 y 403 también son fallos. Una página monitorizada que pide iniciar sesión, o que bloquea la petición, se notifica como fallida en lugar de tratarse como sana. Si monitorizas una página protegida por autenticación, elige una dirección pública, como una página de estado de salud.
  • Más de cinco redirecciones es un fallo, igual que la falta de respuesta, un error de conexión, un fallo de DNS o un certificado no válido.

Éxito en la red no es una aplicación sana

Un 200 significa que el servidor respondió con éxito. No significa que la página sea correcta. Un proceso de pago roto que aun así muestra una página normal, una página vacía donde debería haber datos o un mensaje de error en el cuerpo de una respuesta «200» superan una comprobación HTTP. Consulta tiempo de inactividad para ver qué puede y qué no puede detectar una comprobación así. UptimeWire no ejecuta pruebas completas basadas en un navegador. Comprueba la respuesta a una petición.

Solución de problemas según el código

Ves Dirección probable
404 en una página que existía Una página eliminada o renombrada, una estructura de URL cambiada o un despliegue al que le faltaron archivos
403 en la página de inicio Una regla de cortafuegos o de seguridad, un cambio de permisos en los archivos o un bloqueo de la dirección de la herramienta de comprobación
401 en una página pública Se añadió autenticación a una ruta que antes era abierta
429 Un límite de peticiones. Muchas peticiones desde un mismo origen, incluidas las comprobaciones, pueden activarlo
500 Revisa los registros de la aplicación: un error de código, una dependencia que falla o una mala configuración
502 El servicio que hay detrás del proxy está caído, se ha bloqueado o se está reiniciando
503 Mantenimiento o sobrecarga. Revisa el uso de recursos y si hay un despliegue en curso
504 El servicio que hay detrás del proxy es demasiado lento. Mira las peticiones de larga duración y la base de datos
Bucle de redirecciones Dos reglas que se devuelven las peticiones una a otra, a menudo ajustes de http y https o de www

Cuando aparezca un código, mira también el tiempo de respuesta. Un aumento del tiempo de respuesta suele aparecer justo antes de que empiecen los errores 504 o 503.