En la monitorización de disponibilidad, la respuesta corta es esta: las respuestas 2xx significan que todo funciona, las 5xx significan caída, y todo lo que hay en medio depende de lo que esperes de esa URL. Un 301 está bien si la página se ha movido a propósito, un 401 está bien en un endpoint de API que exige una clave, y un 404 en tu página de pago es una caída. Un buen monitor comprueba el código de estado que esperas, no simplemente «cualquier cosa que no sea un error».
Esta chuleta repasa las familias de códigos de estado desde el punto de vista de la monitorización: qué significa cada código, si debe contar como caída y cómo configurar las comprobaciones para que solo avisen de problemas reales.
Las cinco familias de un vistazo
RangoSignificadoPara un monitor1xxInformativo, la petición continúaPoco habitual; no es una respuesta final2xxÉxitoNormalmente, funciona3xxRedirección, busca en otro sitioFunciona o está caído según la intención4xxError del cliente, la petición era incorrectaDepende del endpoint5xxError del servidor, el servidor ha falladoCaído
El primer dígito te dice quién es el responsable. Un 4xx significa que el servidor considera que la petición era incorrecta. Un 5xx significa que el servidor reconoce que ha fallado. En un monitor que envía la misma petición cada minuto, un 4xx repentino suele indicar que algo ha cambiado en el servidor de todos modos: se ha eliminado una página, ha cambiado un permiso o un firewall ha empezado a bloquear.
1xx: informativos
Códigos como 100 Continue, 101 Switching Protocols y 103 Early Hints son respuestas provisionales. El cliente las ve antes de la respuesta final, o no las ve en absoluto. Una comprobación de monitorización espera al código de estado final, así que puedes ignorar esta familia. Si una comprobación termina alguna vez en un 1xx, la conexión se ha cortado a mitad de la respuesta, y eso es un fallo.
2xx: éxito
CódigoNombreNotas para la monitorización200OKLa respuesta de éxito estándar201CreatedLo esperado tras un POST que crea algo202AcceptedPetición en cola; el trabajo se hace más tarde204No ContentÉxito con el cuerpo vacío; habitual en DELETE y en algunos health checks
Un 200 no garantiza que la página funcione. Muchas aplicaciones capturan sus propios errores y muestran una página de error con estado 200: «Database connection failed», una plantilla en blanco, un aviso de mantenimiento. Añade validación de contenido a las comprobaciones importantes: espera una palabra o un campo JSON que solo aparezca cuando la página funciona de verdad. Con un 204 no hay cuerpo que validar, así que comprueba solo el código de estado.
3xx: redirecciones
CódigoNombreUso habitual301Moved PermanentlyDe una URL antigua a la nueva, de HTTP a HTTPS302FoundRedirección temporal, a menudo a una página de inicio de sesión303See OtherRedirección tras enviar un formulario por POST304Not ModifiedLa copia en caché sigue siendo válida; solo tras peticiones condicionales307Temporary RedirectComo el 302, pero conserva el método y el cuerpo308Permanent RedirectComo el 301, pero conserva el método y el cuerpo
Redirecciones y monitores
Las herramientas de monitorización tratan las redirecciones de una de estas dos formas: las siguen e informan del estado de la página final, o se detienen en la primera respuesta e informan del 3xx. Averigua qué hace tu herramienta en cada comprobación, porque las dos opciones pueden ocultar problemas:
Si el monitor sigue las redirecciones, una página que de repente redirige a la portada o a una pantalla de inicio de sesión puede seguir terminando en un 200. La validación de contenido lo detecta: la portada no contiene las palabras de tu página de pago.
Si el monitor no sigue las redirecciones, configura como estado esperado el código de la redirección y comprueba la URL final con su propio monitor.
Lo más seguro es monitorizar directamente la URL final. Si northwind.shop redirige a www.northwind.shop, monitoriza la versión con www y añade una comprobación aparte para la redirección solo si te importa, por ejemplo para enlaces de campañas antiguas. Un bucle de redirecciones, en el que dos URL apuntan la una a la otra, aparece como un timeout o un error de «too many redirects» y siempre debe contar como caída.
4xx: errores del cliente
CódigoNombre¿Caída?400Bad RequestNormalmente, una comprobación rota o una API que ha cambiado401UnauthorizedLo esperado en endpoints protegidos sin credenciales403ForbiddenLo esperado en rutas bloqueadas; un problema si aparece de repente404Not FoundCaída en cualquier URL que debería existir405Method Not AllowedLa comprobación usa un método incorrecto o la ruta ha cambiado408Request TimeoutEl servidor se cansó de esperar la petición410GoneEliminado a propósito429Too Many RequestsLímite de peticiones alcanzado
401 y 403 en endpoints protegidos
Algunos endpoints deben rechazar las peticiones anónimas. Una API de administración que devuelve 401 sin token funciona correctamente. Puedes monitorizarla de dos formas:
Espera el rechazo. Configura 401 como estado esperado. La comprobación confirma que el servidor funciona y que la capa de autenticación está en su sitio. Si alguna vez devuelve 200 sin credenciales, tienes un problema de seguridad que merece una alerta.
Envía credenciales. Añade a la comprobación una cabecera con una clave de API o autenticación básica y espera un 200 con el contenido correcto. Así pruebas el recorrido completo, incluida la base de datos que hay detrás del endpoint.
La segunda opción prueba más cosas, así que úsala para todo aquello de lo que dependen tus clientes. Usa una clave de solo lectura dedicada a la monitorización, nunca una clave personal o de administrador.
Un 403 repentino en una página pública es otra historia. Suele significar que un firewall, un plugin de seguridad o una regla de la CDN ha empezado a bloquear peticiones, a veces solo desde ciertos países o rangos de IP. Si una ubicación de monitorización recibe un 403 y otra un 200, lo más probable es que la causa sea una regla geográfica o de IP.
429 Too Many Requests
Un 429 significa que el servidor está limitando las peticiones del cliente. Para la monitorización, puede significar dos cosas: tus límites son demasiado estrictos para el tráfico normal, o el propio monitor está alcanzando un límite porque comparte dirección con otros clientes. Revisa la cabecera Retry-After y tu configuración de límites. Si usuarios reales reciben 429 con una carga normal, trátalo como una caída.
5xx: errores del servidor
CódigoNombreQué suele significar500Internal Server ErrorLa aplicación ha fallado con esta petición501Not ImplementedEl servidor no admite el método502Bad GatewayEl proxy ha recibido una respuesta no válida de la aplicación que tiene detrás503Service UnavailableSobrecarga, mantenimiento o ningún backend sano504Gateway TimeoutEl proxy ha esperado demasiado a la aplicación
Trata cualquier 5xx como una caída. Los códigos se diferencian en dónde mirar primero: un 500 apunta a los logs de la aplicación, un 502 a un proceso de la aplicación caído o reiniciándose, un 504 a consultas lentas o llamadas externas, y un 503 a falta de capacidad o a un mantenimiento. Nuestra guía sobre el error 503 Service Unavailable repasa en detalle las causas y las soluciones.
Algunas CDN y proxies usan sus propios códigos en el rango 5xx, como del 520 al 530, para problemas entre la CDN y tu servidor de origen. No forman parte del estándar HTTP, pero para un visitante significan lo mismo: la web está caída.
No todos los fallos tienen código de estado
Algunas de las caídas más habituales no generan ningún código de estado:
Fallo de DNS: el dominio no se resuelve, por ejemplo porque ha caducado el registro o se ha eliminado un registro DNS.
Conexión rechazada o reiniciada: no hay nada escuchando en el puerto, o un firewall corta la conexión.
Errores de TLS: un certificado caducado o que no coincide detiene la petición antes de que llegue a haber HTTP.
Timeouts: el servidor acepta la conexión, pero nunca responde a tiempo.
Un buen monitor los notifica como fallos con el error concreto, para que la alerta diga «certificado caducado» y no solo «caído». Por eso también vale la pena añadir comprobaciones de caducidad del certificado y del dominio junto a tus monitores HTTP.
Cómo configurar el estado esperado en un monitor
Para cada URL que monitorizas, decide qué aspecto tiene una respuesta sana y déjalo por escrito en la configuración de la comprobación:
Elige la URL que importa. La URL final tras las redirecciones, no el enlace corto.
Define el método. GET para páginas, y el que exija el endpoint en el caso de las API.
Define el estado esperado. Normalmente 200. Usa 201, 204, 301 o 401 cuando esa sea la respuesta prevista.
Añade credenciales si hace falta. Cabeceras o autenticación básica para los endpoints protegidos.
Añade validación de contenido. Una palabra de la página o un campo de la respuesta JSON que solo aparezca cuando todo funciona.
Define un timeout. Para un visitante, una respuesta que tarda 30 segundos es un fallo aunque termine en 200.
Así quedaría para un endpoint de salud en lumenanalytics.io, probado primero a mano con curl:
curl -sS -o /dev/null -w «%{http_code} %{time_total}s\n» \
-H «Authorization: Bearer $MONITOR_TOKEN» \
https://api.lumenanalytics.io/v1/health
Si eso devuelve 200 y un tiempo razonable, el mismo método, la misma cabecera y el mismo estado esperado van al monitor. En Uptimecheck, los monitores de disponibilidad y los monitores de API admiten método personalizado, cabeceras (por ejemplo, autenticación básica o un token bearer), cuerpo, palabras clave y comprobaciones JSON, y marcan la comprobación como fallida cuando el código de estado o la respuesta no son los que esperas. Para saber más sobre cómo diseñar el propio endpoint, consulta cómo crear un endpoint de health check, y la checklist de monitorización de API para saber qué endpoints cubrir.
Referencia rápida: ¿está caído?
Caído: cualquier 5xx, un 404 en una URL que debería existir, timeouts, errores de DNS y TLS, conexiones rechazadas.
Probablemente caído: un 403 o un 429 repentinos en una página pública, un 400 o un 405 en una comprobación que antes pasaba.
Funciona: el código de estado que configuraste como esperado, con el contenido que validas, en un tiempo razonable.
Resumen
Los códigos de estado son lo primero que mira un monitor y la forma más rápida de saber dónde está el problema. Un 5xx significa que el servidor ha fallado, un 4xx que algo ha cambiado en lo que el servidor acepta, y un 3xx obliga a decidir dónde debe terminar la comprobación. Configura cada monitor con el estado que debe recibir, valida el contenido de las páginas importantes y deja que la alerta incluya el código, para que quien la reciba sepa por dónde empezar.
Uptimecheck comprueba tus webs y API hasta cada minuto y te avisa cuando el código de estado o la respuesta no son los que esperas. Pruébalo gratis durante 14 días, sin tarjeta de crédito.