Alertas de disponibilidad: por qué saltan si el sitio carga

¿Puede una alerta de disponibilidad ser “verdadera” incluso cuando carga la página de inicio?

Sí. Una pestaña del navegador que muestra tu página de inicio no demuestra que el endpoint monitorizado haya pasado la comprobación de Astrina, y esa diferencia es lo primero que hay que entender cuando te preguntas por qué las alertas de disponibilidad de Astrina se disparan aunque el sitio siga en línea. En otras palabras, es el típico caso de alerta de disponibilidad sitio caído pero carga: una persona puede abrir la página de marketing, ver un logotipo y asumir que todo está bien, mientras Astrina está comprobando /status, /login o una respuesta JSON en lugar de la portada.

Esa separación importa. Una página de inicio puede cargarse desde la caché mientras el endpoint real agota el tiempo de espera en el servidor. Un sitio también puede devolver un 200 para la estructura de la página y aun así fallar la regla de contenido porque falta una cadena obligatoria. Un detalle pequeño, una consecuencia grande.

Piénsalo como dos preguntas distintas: “¿puedo ver algo?” y “¿pasó exactamente la comprobación?”. Esa es, en esencia, la respuesta a por qué mi web carga pero el monitor falla. No son lo mismo.

He aquí un ejemplo sencillo con 3 partes en movimiento: el usuario carga https://example.com, el monitor comprueba https://example.com/api/health y la API devuelve un 500 durante 90 segundos. Puede que los visitantes ni lo noten si la página está en caché, pero Astrina hace bien en disparar la alerta porque el endpoint probado está roto. No es una contradicción; es precisamente el objetivo de la monitorización.

¿Qué parte de la comprobación está fallando realmente?

La forma más rápida de leer una alerta de disponibilidad es aislar la capa que falló. DNS, TCP, TLS, HTTP, redirecciones y comprobaciones del cuerpo fallan por motivos distintos, y cada uno deja un rastro diferente. Si te saltas ese paso, perderás tiempo culpando “al sitio” cuando solo se ha resbalado una capa, incluso si el caso parece un fallo de DNS TLS HTTP en monitorización.

Un fallo de DNS significa que la sonda no pudo encontrar el host. Un fallo de TCP significa que se encontró el host, pero no se pudo abrir la conexión. Un fallo de TLS o SSL significa que el certificado, el nombre del host o el handshake no satisfizo a la sonda. Un fallo de HTTP significa que el servidor respondió, pero con el código de estado incorrecto. Un fallo de redirección significa que la cadena fue a un lugar inesperado o superó un límite. Un fallo de coincidencia de contenido significa que la página cargó, pero el cuerpo no incluía el texto esperado.

Esas categorías son concretas, no estéticas. Una redirección 301 a una página de inicio de sesión puede parecer “en línea” para una persona, pero el monitor puede fallar si espera un 200 en la ruta original. Un certificado que caduca dentro de 2 días puede provocar advertencias en algunos navegadores y en otros no, mientras Astrina ya puede marcar el estado de TLS. Ese es el tipo de diferencia que acaba en una alerta confusa a las 09:17.

Si tu comprobación apunta a un endpoint privado, el fallo puede ser aún más concreto. Un endpoint puede devolver 200 mientras otro devuelve 403 por una regla de autenticación añadida la semana pasada. El sitio está activo, pero la ruta no.

¿Por qué usuarios y monitores ven resultados distintos al mismo tiempo?

Usuarios y monitores no ven la web desde el mismo lugar. Un navegador puede beneficiarse de la caché local, de una sesión activa o de un nodo CDN rápido cerca del visitante. La sonda de Astrina puede llegar desde otra región, por una ruta IP distinta o con una petición en frío, sin estado de navegador alguno.

Esa diferencia explica mucho. Un visitante en Londres carga el sitio en 1 segundo. Otra sonda en una ubicación distinta ve un tiempo de espera agotado a los 5 segundos porque una ruta de tránsito está congestionada. Ambos informes pueden ser ciertos al mismo tiempo.

El comportamiento del CDN es una causa habitual. Si el edge sirve la página de inicio pero no un recurso anidado, la página puede seguir pareciendo “bien” a simple vista. Una estructura en caché puede ocultar un origen roto. El monitor, sin embargo, puede estar comprobando la ruta del origen directamente o una ruta que el CDN no almacena durante mucho tiempo.

Las diferencias geográficas también pueden importar. Un firewall puede permitir tráfico desde la IP de tu oficina y bloquear un rango de IPs de la sonda. Un problema de enrutamiento puede afectar a un continente durante 12 minutos y dejar intacto el resto. Ese tipo de vista dividida es molesto, pero es real. Ninguna mano extendida cambia la ruta de los paquetes.

A veces el resultado es todavía más simple: un navegador reintenta automáticamente, mientras que un monitor no. Una página que termina cargando después de 3 intentos fallidos aún puede disparar una alerta si la comprobación agota el tiempo en el primer intento. Eso no significa que Astrina sea “demasiado estricta”. Significa que el servicio está coqueteando con el fallo.

¿Podría una interrupción parcial disparar una alerta aunque el sitio principal funcione?

Sí, y este es uno de los patrones más comunes. El sitio público puede seguir siendo accesible mientras una dependencia falla entre bastidores. Una API de compra, un servicio de imágenes o un backend de búsqueda puede caerse sin tumbar la página de inicio.

Considera un sitio de comercio electrónico con 4 capas: la página de inicio, la API de productos, la pasarela de pago y el servicio de inventario. Si la página de inicio está en caché pero la API de productos devuelve resultados vacíos, un visitante puede seguir aterrizando en la página y ver un banner. Astrina podría comprobar el endpoint de la API y disparar la alerta de inmediato. El sitio está “arriba” en un sentido informal, pero una función clave está caída.

Un único recurso roto también puede importar. Si tu monitor verifica que la imagen principal o un paquete JavaScript está presente, un archivo que falta puede hacer fallar la comprobación de contenido aunque el HTML cargue. Un solo archivo ausente puede bastar. No es dramático; es la realidad operativa.

Los fallos específicos por región crean un problema similar. Supón que un centro de datos sirve a usuarios de un país, mientras que otra región está degradada. El sitio principal puede cargar desde la región sana, pero las solicitudes desde la región rota agotan el tiempo o devuelven errores. La alerta no está equivocada. Te está diciendo que la disponibilidad no es uniforme.

Hay un caso más sutil: una dependencia lenta puede empujar la respuesta más allá del límite de la comprobación. Una página puede renderizarse finalmente después de 8 segundos, pero si el umbral del monitor es de 5 segundos, Astrina disparará la alerta. Eso es útil. La lentitud suele ser el primer paso antes de la caída.

¿Qué detalles de la respuesta deberías inspeccionar primero?

Empieza por los campos que te dicen qué falló, no lo que esperas que haya fallado. Los primeros elementos que debes revisar son el código de estado, el tiempo de respuesta, la coincidencia del cuerpo, el estado del certificado y la cadena de redirecciones. Si la alerta incluye una ubicación de la sonda, léela también, porque la ubicación puede explicar un problema específico de la ruta.

Lee esos campos en ese orden. Un 500 es un problema distinto de un 200 con el cuerpo incorrecto. Un tiempo de espera agotado es diferente otra vez. Si ves una cadena de redirecciones de 4 saltos, pregúntate si el monitor debería seguir los 4 o si debería vigilar un endpoint más simple. Cuantos más saltos, más lugares donde fallar.

La ubicación de la sonda merece una segunda mirada. Un resultado desde Fráncfort puede diferir de uno desde Singapur si un nodo CDN o una ruta ascendente es inestable. Ese detalle suele explicar por qué un operador ve una caída mientras otro no ve nada. Ambos operadores dicen la verdad desde su lado.

Si tu alerta incluye encabezados, vigila los relacionados con la caché. Una respuesta servida desde caché puede ocultar durante un tiempo un fallo del origen. Una respuesta marcada como “stale” o “miss” puede revelar la condición real. Los pequeños indicios importan.

¿Cuándo es más probable que sea un falso positivo y cuándo un problema real de disponibilidad?

Un falso positivo suele ser estrecho y repetible de una manera muy concreta. Un problema real de disponibilidad suele afectar a más de una comprobación o hacerse más fácil de reproducir. Esa distinción ahorra tiempo. También evita que “arregles” el monitor cuando el problema está en el servicio.

Busca primero una dependencia inestable. Si la alerta aparece una vez, desaparece y no vuelve durante los siguientes 30 minutos, es posible que haya habido un problema transitorio aguas arriba. Si se dispara cada 2 minutos en el mismo endpoint, la comprobación puede ser demasiado estricta o el servicio puede estar realmente inestable. Los patrones importan más que las historias.

Una comprobación demasiado estricta suele verse así: la página se renderiza, pero una aserción de contenido espera una frase exacta que cambió en la última versión. El equipo de producto cambió “Iniciar sesión” por “Acceder”, y el monitor empezó a fallar por un desajuste de contenido. El sitio está en línea. La comprobación está desactualizada.

En cambio, un problema genuino suele mostrar señales en más de un sitio. La página de inicio carga lentamente, la API devuelve 503 y el certificado está cerca de caducar. No es una rareza aislada. Es una pila de pequeñas advertencias que apuntan en la misma dirección.

También existe el caso de “depende a quién le preguntes”. Los usuarios detrás de una VPN corporativa pueden llegar por una ruta estable, mientras que la sonda llega por una rota. Al principio puede parecer un falso positivo, pero normalmente es un problema real de accesibilidad para al menos una audiencia. Un sitio que está operativo para el 80% de los visitantes no está completamente operativo.

¿Qué deberías cambiar si el sitio está “arriba” pero Astrina sigue disparándose?

Haz que el objetivo monitorizado coincida con lo que de verdad te importa. Si la página de inicio está bien pero la API es lo importante, monitoriza la API. Si la página de inicio es demasiado ruidosa, mueve la comprobación a un endpoint de salud más limpio. Ese único cambio puede eliminar mucho ruido.

Después, ajusta la regla de contenido solo cuando la regla sea el problema. Una comprobación de una frase concreta es útil si la frase es estable. Es menos útil si el texto cambia con cada versión o localización. Si mantienes una comprobación del cuerpo, elige una cadena que sea poco probable que cambie con una actualización menor de contenido.

También deberías revisar la ruta de redirección. Un 302 hacia una página de inicio de sesión puede ser aceptable para usuarios, pero no para un monitor. En ese caso, monitoriza el endpoint que representa la salud del servicio en lugar de la ruta pública. Es una decisión de configuración, no filosófica.

Si el problema es el tiempo, establece una ruta monitorizada más ligera. Una página de inicio completa con 12 recursos es una mala señal de salud si lo único que necesitas es una respuesta rápida. Un endpoint más ligero ofrece una mejor respuesta y menos falsas alarmas. Las comprobaciones rápidas envejecen mejor que las sofisticadas.

Si aún estás configurando el monitor, la ruta de configuración del agente está aquí: * y el tamaño normalizado del texto visible. Si además necesitas seguir la configuración relacionada en analíticas, consulta cómo añadir astrina a google. Y si gestionas varias propiedades, el artículo sobre astrina para clientes de agencia con múltiples sitios es un siguiente paso útil.

Una última comprobación: compara lo que dice la alerta con la URL exacta, no con el nombre de la marca. Si la alerta se dispara en /api/health y la página de inicio está activa, ese comportamiento es el esperado. Si la alerta se dispara en la propia página de inicio, entonces el problema merece una mirada más profunda, porque una página de inicio que sirve pero falla en comprobaciones de contenido, TLS o enrutamiento sigue siendo un incidente real para Astrina.