HTTP 200 no significa que la aplicación funcione. ¿Qué debería comprobar realmente la monitorización?

1. cada pocos minutos envía una solicitud HTTP,
2. el servidor responde,
3. el sistema comprueba el código de respuesta,
4. si recibe 200 OK, considera que el sitio web funciona.

El problema es que:

HTTP 200 solo significa que el servidor ha devuelto una respuesta HTTP con el código 200. No significa que la aplicación funcione realmente de forma correcta.

Una tienda online puede devolver 200 OK aunque no sea posible añadir un producto al carrito.

El panel del cliente puede funcionar, pero el inicio de sesión puede terminar con un error.

El sitio web puede abrirse, pero su API puede tardar 15 segundos en responder.

El checkout puede mostrarse correctamente, pero todos los intentos de pago pueden terminar con un error.

En todos estos casos, una monitorización que solo muestra un «UP» en verde puede considerar que todo funciona correctamente.

El uptime y el correcto funcionamiento de una aplicación son dos cosas diferentes

Supongamos que monitorizamos:

https://example.com

El sistema realiza una solicitud:

GET /

El servidor responde:

HTTP/1.1 200 OK

Desde el punto de vista de una monitorización básica de uptime, todo está bien.

Pero un usuario no utiliza un sitio web comprobando su código HTTP.

El usuario:

• abre el sitio web,
• hace clic,
• realiza búsquedas,
• inicia sesión,
• envía formularios,
• añade productos al carrito,
• realiza pagos,
• utiliza la API.

Por eso, la pregunta:

«¿Responde el servidor?»

es solo el primer nivel de monitorización.

Una pregunta mucho más importante es:

«¿Puede el usuario hacer aquello para lo que ha venido al sitio web?»

Caso 1: el sitio web devuelve 200, pero muestra un mensaje de error

Imaginemos una aplicación en la que se ha producido un problema con la base de datos.

El backend captura la excepción y, en lugar de devolver HTTP 500, renderiza su propia página de error.

La respuesta puede ser así:

HTTP/1.1 200 OK
Content-Type: text/html

y su contenido:

<h1>Something went wrong</h1>
<p>Please try again later.</p>

Para el usuario, la aplicación no funciona.

Para una monitorización básica:

200 OK

es decir, todo está bien.

Por eso, una buena monitorización HTTP no debería limitarse únicamente al estado de la respuesta.

En determinados casos, también conviene comprobar su contenido.

Por ejemplo, se puede comprobar que la página contenga un elemento o texto específico que indique que la aplicación se ha cargado correctamente.

Caso 2: la página de inicio funciona, pero el checkout no

Este es uno de los problemas más importantes en la monitorización de tiendas online.

La monitorización comprueba:

GET /

y recibe:

200 OK

Mientras tanto:

/cart

funciona, pero:

/checkout

termina con un error.

O peor aún: el checkout también devuelve 200, pero el JavaScript responsable de seleccionar el método de pago ha dejado de funcionar.

Desde el punto de vista de la infraestructura, la tienda está disponible.

Desde el punto de vista del negocio, la tienda puede estar prácticamente fuera de servicio.

Si el usuario no puede pagar, que la página de inicio funcione tiene poca importancia.

Por eso, la monitorización debería incluir los procesos de negocio más importantes, y no solo la página de inicio.

En una tienda online pueden ser:

• la página de inicio,
• la página de producto,
• el buscador,
• el carrito,
• el checkout,
• los endpoints de pago,
• la API responsable del stock.

En una aplicación SaaS:

• el inicio de sesión,
• el registro,
• el dashboard,
• la función principal de la aplicación,
• la API,
• las colas o tareas programadas.

Caso 3: la aplicación funciona, pero es tan lenta que prácticamente no funciona

Otro problema aparece cuando la respuesta es así:

HTTP 200
Response time: 12.8 s

¿Funciona la aplicación?

Técnicamente, sí.

¿Considerará el usuario que funciona correctamente?

No necesariamente.

Por eso, la monitorización debería analizar no solo la disponibilidad, sino también el tiempo de respuesta.

También conviene tener cuidado con los picos puntuales.

Si el tiempo de respuesta habitual es de 300 ms y una solicitud tarda 900 ms, no tiene por qué significar que exista una incidencia.

Sin embargo, si durante los últimos 20 minutos los tiempos de respuesta han aumentado así:

300 ms → 450 ms → 800 ms → 1.4 s → 2.8 s

tenemos una señal mucho más interesante.

La aplicación todavía funciona, pero su estado está empeorando claramente.

A menudo, este es el mejor momento para reaccionar: antes de que se produzca una caída completa.

Caso 4: el frontend funciona, pero la API no

Las aplicaciones modernas suelen estar formadas por muchos componentes independientes.

Por ejemplo:

Frontend
   ↓
API
   ↓
Database
   ↓
Redis
   ↓
Queue
   ↓
External services

El simple hecho de abrir el frontend puede no activar todas estas dependencias.

Una aplicación Next.js puede renderizar correctamente una página mientras que la API del backend devuelve errores.

Del mismo modo, el panel de administración puede abrirse aunque la cola haya dejado de procesar tareas.

Por eso, monitorizar únicamente la URL pública no ofrece una visión completa del estado de la aplicación.

Caso 5: los errores solo afectan a una parte de los usuarios

Las incidencias parciales son aún más difíciles de detectar.

Por ejemplo, un problema puede producirse únicamente:

• en dispositivos móviles,
• en un navegador específico,
• para usuarios de un país determinado,
• después de iniciar sesión,
• con un método de pago concreto,
• en un único endpoint de la API.

Desde el punto de vista de una monitorización básica de uptime, la aplicación puede parecer completamente saludable en todo momento.

Esto demuestra por qué conviene combinar la monitorización externa con la monitorización de errores dentro de la propia aplicación.

El uptime y la monitorización de errores responden a preguntas diferentes

La monitorización de uptime responde principalmente a la pregunta:

«¿Es posible conectarse al servicio desde el exterior?»

La monitorización de errores, en cambio, responde a la pregunta:

«¿Se producen errores durante el funcionamiento de la aplicación?»

Son dos perspectivas diferentes.

Supongamos que, en una hora, una aplicación ha procesado:

100 000 solicitudes

y el 2 % de ellas ha terminado con un error de la aplicación.

Eso supone:

2 000 solicitudes con errores

Al mismo tiempo, durante cada comprobación de la monitorización, la página de inicio podría haber devuelto:

200 OK

Uptime:

100%

Sin embargo, esto no significa que la aplicación haya funcionado sin problemas.

La monitorización debería funcionar por capas

En lugar de intentar responder con un único indicador a la pregunta «¿funciona todo?», es mejor observar varias capas independientes.

Capa 1: disponibilidad

¿Responde el servidor?

Comprobamos, entre otras cosas:

• el código HTTP,
• los timeouts,
• los problemas de DNS,
• los problemas de conexión,
• las redirecciones.

Capa 2: tiempo de respuesta

¿Con qué rapidez responde la aplicación?

No solo nos interesa el valor actual, sino también cómo cambia con el tiempo.

Una caída repentina del rendimiento puede ser la primera señal de un problema.

Capa 3: certificado SSL

¿El certificado:

• es válido,
• no ha caducado,
• no caducará dentro de pocos días?

Una incidencia relacionada con SSL es especialmente innecesaria, ya que normalmente puede detectarse mucho antes de que se convierta en un problema.

Capa 4: contenido de la respuesta

¿Ha devuelto el servidor lo que esperábamos?

El estado 200 por sí solo puede no ser suficiente.

Capa 5: errores de la aplicación

¿Está generando excepciones el backend?

Conviene observar, entre otros datos:

• el tipo de error,
• el stack trace,
• el endpoint,
• el entorno,
• la versión de la aplicación,
• el momento de la primera y la última aparición,
• la frecuencia con la que se produce.

Capa 6: rendimiento del sitio web

Una aplicación puede responder rápidamente a nivel HTTP y, aun así, funcionar lentamente en el navegador.

Por eso, también conviene monitorizar el rendimiento del frontend y Core Web Vitals.

Capa 7: proceso de negocio

El nivel más alto de monitorización responde a la pregunta:

«¿Puede el usuario realizar realmente la acción más importante?»

Para una tienda online, será completar una compra.

Para un SaaS, puede ser iniciar sesión y realizar la operación principal.

Para un sitio web de captación de leads, será enviar un formulario.

Las incidencias más peligrosas no siempre significan un downtime completo

Paradójicamente, una caída completa es fácil de detectar.

Si el servidor deja de responder y empieza a devolver:

502 Bad Gateway

la monitorización detectará rápidamente el problema.

Mucho más difíciles de detectar son las incidencias del tipo:

el sitio web funciona, pero algo importante ha dejado de funcionar.

Precisamente estos problemas pueden pasar desapercibidos durante muchas horas.

La tienda funciona, pero no acepta pedidos.

El formulario parece funcionar, pero no envía los mensajes.

La aplicación funciona, pero algunos usuarios no pueden iniciar sesión.

La API funciona, pero un endpoint crítico devuelve errores.

Por eso, una monitorización eficaz no debería reducir todo el estado de la aplicación a un único indicador verde o rojo.

Entonces, ¿qué significa que «la aplicación funciona»?

No existe una única respuesta universal.

Una aplicación bien monitorizada debería observarse desde varias perspectivas al mismo tiempo:

• si responde,
• si responde con suficiente rapidez,
• si devuelve el contenido correcto,
• si no genera un número inusual de errores,
• si su certificado es válido,
• si el frontend funciona con un buen rendimiento,
• si las funciones de negocio más importantes están disponibles.

Solo la combinación de toda esta información ofrece una imagen real del estado de la aplicación.

HTTP 200 es una señal importante. Pero es solo una de ellas.