Un 99,9 % de uptime no significa que el sitio de un cliente funcione

Un sitio de cliente con "99,9 % de uptime" suena seguro. Esa cifra aún permite 8,76 horas de caída al año, o unos 43 minutos en un mes de 30 días. Y solo cuenta el tiempo en que el servidor no respondió en absoluto.

La brecha más grande está en lo que una comprobación de uptime considera "activo". Un sitio puede responder a todas las comprobaciones y seguir roto para quienes lo visitan.

Qué mide realmente una comprobación de uptime

Una comprobación HTTP básica hace una sola pregunta: ¿responde el servidor con un código de estado que signifique éxito? Mira el código de estado y nada más. No lee la página.

Así que cada uno de estos casos pasa como "activo", siempre que responda con un estado de éxito:

• una página en blanco por un fallo de la caché, del tema o del constructor de páginas
• una página del proveedor de hosting de "cuenta suspendida" o "límite superado"
• la página de un registrador tras vencer el registro del dominio: cuando vence un dominio de tipo .com, el registrador tiene que impedir que resuelva a tu sitio y puede mostrar en su lugar una página de renovación
• una redirección a una página que a su vez está rota, si la comprobación no sigue las redirecciones
• un formulario de contacto o un checkout que carga, pero falla cuando alguien lo envía

También está el hueco entre comprobaciones. Con una comprobación cada 5 minutos, una caída de 3 minutos puede empezar y terminar entre dos comprobaciones y no aparecer nunca en la cifra de uptime.

Comprueba el contenido, no solo el código de estado

Una comprobación de palabra clave descarga la página y busca un fragmento de texto. Funciona en dos direcciones:

• Falla cuando falta el texto. Elige un texto que solo esté ahí cuando la página funciona de verdad. Una respuesta vacía, un aviso de suspensión o la página de un registrador no lo contendrán.
• Falla cuando aparece el texto. Elige un texto que solo aparezca cuando algo va mal, como "Fatal error" o "Database error".

Elegir el texto es la mayor parte del trabajo:

• Usa texto que el servidor envía en el HTML. Una comprobación de palabra clave lee el código fuente de la página, no lo que JavaScript añade después de que la página carga.
• Usa texto que el CMS genera a partir de su contenido, como el título de una sección o el teléfono del pie de página. Evita texto que también podría contener una plantilla de error estática, como el nombre del sitio.
• Evita texto que cambia: precios, fechas, el título de la última entrada.
• Comprueba la URL final. Si example.com redirige a https://www.example.com/, monitoriza la segunda.

Una comprobación de palabra clave en la página de inicio y otra en la página que le hace ganar dinero al cliente (la página de reservas, una categoría de la tienda, la página de contacto) cubren casi todo lo que notaría un visitante.

Lento no es caído

Una comprobación de uptime le da al servidor varios segundos antes de registrar un tiempo de espera agotado. Una página que tarda ocho segundos en aparecer no está "caída", pero para un visitante es como si lo estuviera.

La lentitud se nota en dos lugares:

• El tiempo de respuesta de cada comprobación. Una tendencia al alza después de un cambio de hosting o de actualizar un plugin es la primera señal. Mide lo rápido que responde el servidor, no cuánto tarda la página en renderizarse.
• Una prueba de velocidad de página. Lighthouse, que también está detrás de Google PageSpeed Insights, mide cómo carga la página en un navegador. Una comprobación de uptime no puede hacerlo.

Revisa ambos después de cada actualización, no solo cuando el cliente se queje.

Cuando "caído" no es caído

También ocurre lo contrario. Algunos sitios están detrás de una protección contra bots que puede responder a un servicio de monitorización en un centro de datos de forma distinta que al navegador de un visitante. El monitor informa entonces de que el sitio está caído, mientras se abre sin problemas para todos los demás.

Nos pasó a principios de septiembre de 2026: un monitor de un gran sitio web público se quedó en Caído durante un incidente largo, mientras la página cargaba con normalidad en un navegador y todas las comprobaciones desde otras regiones lo daban por activo. Antes de llamar a un cliente por una caída, abre el sitio tú mismo desde una conexión normal.

Lo que ninguna comprobación de uptime cubre

Las comprobaciones de uptime y de palabra clave cargan una URL. No inician sesión, no rellenan formularios, no añaden productos al carrito ni pagan. Baromio tampoco ejecuta recorridos de varios pasos con scripts.

Si los ingresos de un cliente dependen de un flujo así, pruébalo a mano después de cada actualización de plugins, del tema o del sistema de pago: envíate el formulario de contacto a ti mismo, haz un pedido de prueba, inicia sesión con una cuenta de prueba. Lleva unos minutos y detecta lo que una comprobación de URL no puede.

Cómo configurarlo en Baromio

• Monitor HTTP: envía una solicitud HEAD (GET si el servidor rechaza HEAD), considera activo cualquier estado por debajo de 400 y no sigue redirecciones. Responde a la pregunta "¿responde el servidor?".
• Monitor de palabra clave: obtiene la página con GET y busca tu texto en el código fuente HTML, sin distinguir entre mayúsculas y minúsculas. Tú eliges si la comprobación falla cuando falta el texto o cuando se encuentra. Dale la URL final, después de cualquier redirección.
• Tiempo de Respuesta: se guarda el tiempo de respuesta de cada comprobación, y la página del monitor lo muestra en un gráfico de las últimas 24 horas, 7 días o 30 días. No hay alerta de "más lento que X milisegundos". Alertar después de define cuántas comprobaciones fallidas seguidas (1, 2, 3 o 5) hacen falta antes de que recibas una alerta, lo que mantiene los fallos puntuales fuera de tu bandeja de entrada.
• Discrepancia Regional: mientras un monitor HTTP o de palabra clave está caído, Baromio vuelve a comprobar el sitio desde otras ubicaciones. Si todas llegan a él dos ciclos seguidos, la tarjeta del monitor muestra una insignia CUESTIONADO y la página del incidente explica por qué. Nunca cambia la alerta ni la recuperación; solo te avisa de que el estado Caído puede ser una falsa alarma. Está en todos los planes.
• Velocidad de Página: activa Monitorear Velocidad de Página en un monitor HTTP o de palabra clave para ejecutar Lighthouse a través de Google PageSpeed Insights: 1 URL por semana en Free, 5 URL al día en Pro, 15 al día en Business.
• Intervalos: cada 5 minutos en Free (20 monitores), cada minuto en Pro (9 EUR al mes, 30 monitores), cada 30 segundos en Business (29 EUR al mes, 100 monitores).

Una lista de comprobación para cada sitio de cliente

1. Un monitor HTTP en la página de inicio.
2. Un monitor de palabra clave en la página más importante, configurado para fallar cuando falte un fragmento de contenido real.
3. Un vistazo al gráfico de tiempo de respuesta después de cada cambio de hosting o actualización importante.
4. Una prueba manual de formularios, inicios de sesión y checkout después de cada actualización.
5. Antes de avisar al cliente de una caída, abre el sitio tú mismo.

Fuentes

• ICANN, Expired Registration Recovery Policy: tras el vencimiento, el registrador debe interrumpir la ruta de resolución DNS del dominio; la página de destino que se muestre en su lugar debe indicar que el registro ha vencido.