Un propietario del sitio usualmente descubre que su sitio está caído de la misma manera que los clientes: a través de un correo de soporte, una notificación de contracargo o una caída en el proceso de compra que aparece en el panel de análisis a la mañana siguiente. Para ese momento, el incidente tiene horas de antigüedad y los ingresos se han perdido.
El monitoreo de disponibilidad del sitio web es la práctica de detectar fallos antes de que eso suceda. Pero “¿está el sitio activo?” resulta ser una pregunta más difícil de lo que parece. Un sitio puede devolver un 200 OK mientras el botón de compra está roto. Un sitio puede ser accesible desde EE.UU. y estar caído en Europa. Un sitio puede estar técnicamente en línea y aún fallar para los usuarios porque el proveedor de DNS está agotando el tiempo de respuesta o el certificado SSL expiró a las 2 a.m.
Esta guía cubre el lado operativo del monitoreo de disponibilidad del sitio web: qué verificar, de dónde verificar, con qué frecuencia y qué hacer cuando se dispara una alerta. Está escrita para propietarios que gestionan su propio sitio, no para equipos SRE con un muro de paneles dedicado. El objetivo es configurar un monitoreo en el que puedas confiar y luego ignorarlo hasta que te envíe una alerta.
Qué Significa Realmente “Disponible”
Hay una brecha entre “el servidor respondió” y “un usuario pudo comprar algo”. El monitoreo de disponibilidad vive en esa brecha.
Una simple verificación de tiempo activo hace ping a tu URL y busca un código de estado 200. Ese es el nivel básico. Detecta fallas catastróficas (servidor caído, DNS roto, red inalcanzable) y no detecta fallas más sutiles: un procesador de pagos que da error 500 en la compra, una configuración CDN que sirve una página en blanco, un error de JavaScript que rompe el botón de inicio de sesión en Safari.
El monitoreo de disponibilidad real apila verificaciones unas sobre otras para que “el sitio esté activo” signifique que un usuario real, en un navegador real, en una ubicación real, pueda hacer lo que vino a hacer. El glosario de Dotcom-Monitor tiene una definición más completa de disponibilidad del sitio web si quieres la versión formal.
Un patrón común de fallo real: una implementación el viernes por la noche introduce una nueva etiqueta de análisis. El HTML sigue devolviendo 200 OK desde todas las regiones, por lo que una herramienta básica de uptime reporta verde todo el fin de semana. El lunes por la mañana, el soporte está abrumado con tickets porque la etiqueta de terceros bloquea el manejador de envío del formulario de compra en Safari. Una verificación con navegador real en la página de checkout habría detectado la falla dentro de un intervalo de sondeo. Una simple verificación HTTP no.
Por Qué Importa el Monitoreo de Disponibilidad
El costo del tiempo de inactividad varía mucho según el negocio, pero las categorías de daño son consistentes: transacciones perdidas, SLAs incumplidos, daño a la reputación de la marca y penalizaciones en ranking de búsqueda por rastreadores que encuentran páginas de error durante una caída prolongada, además del costo interno del manejo de incidentes de emergencia.
Para sitios de comercio electrónico, incluso unos minutos de inactividad durante el tráfico pico pueden significar miles de dólares en pedidos perdidos. Para proveedores SaaS, una sola caída prolongada puede activar créditos de SLA y erosionar la confianza del cliente que tomó años construir. Para sitios de medios y publicaciones, el tiempo de inactividad en una noticia de última hora es tráfico que simplemente nunca regresa.
El monitoreo de disponibilidad reduce la ventana entre que algo sale mal y alguien lo soluciona. Ese tiempo medio hasta la detección (MTTD) es a menudo la palanca más grande para reducir el impacto total de un incidente.
Cómo Funciona el Monitoreo de Disponibilidad
La mayoría del monitoreo de disponibilidad depende de verificaciones sintéticas: solicitudes automáticas enviadas desde nodos de monitoreo distribuidos por el mundo. Estas verificaciones se realizan a intervalos regulares — desde cada pocos segundos hasta cada pocos minutos — y registran si el objetivo respondió correctamente dentro de un tiempo aceptable.
Una verificación típica involucra un agente de monitoreo en una ubicación geográfica específica enviando una solicitud HTTP a tu URL, y luego evaluando la respuesta contra un conjunto de reglas. ¿Devolvió un código de estado 2xx, o provocó un error crítico del servidor? ¿El tiempo de respuesta estuvo bajo el umbral? ¿La página contenía el contenido esperado? ¿Todos los recursos de la página se cargaron con éxito?
Cuando una verificación falla, el sistema de monitoreo no suele disparar una alerta inmediatamente. En su lugar, usualmente reintenta desde el mismo nodo y, tan importante, desde diferentes nodos. Esto filtra picos transitorios en la red y problemas localizados en el nodo de monitoreo, que de otro modo generarían falsas alarmas constantes. Solo cuando las fallas se confirman en múltiples ubicaciones, el sistema escala a una alerta.
Cómo Monitorear el Tiempo Activo del Sitio Web: Las Cinco Verificaciones Que Todo Sitio Necesita
El consejo estándar es “monitorea el tiempo activo”. Eso pierde la mayoría de las formas de fallo. A continuación, las cinco tipos de chequeos que detectan los fallos que los propietarios de sitios realmente ven en producción.
1. Verificación de Estado HTTP(S)
La verificación básica. Se accede a una URL, se espera una respuesta 2xx, se alerta cualquier otro resultado. Configúrala para la página principal, la página de precios, el checkout y cualquier página de aterrizaje relacionada con tráfico pagado. Esto detecta caídas graves y fallos en el apretón de manos SSL.
Ejecuta la verificación desde múltiples ubicaciones. Una verificación desde un único centro de datos en EE.UU. reportará “activo” mientras clientes en Sídney ven un error de CloudFront.
2. Verificación de Resolución DNS
Un sitio que no puede resolverse es un sitio que no existe, aunque el servidor esté saludable. Los problemas de DNS usualmente se deben a caídas del proveedor (Route 53 ha tenido algunas notables), dominios expirados o problemas de propagación tras un cambio de registro.
Una verificación de monitoreo DNS resuelve tu dominio contra varios resolutores públicos y alerta cuando la respuesta cambia inesperadamente o la consulta falla por completo.
3. Validez del Certificado SSL
Los certificados expiran. Se revocan. Se configuran mal durante una renovación de Let’s Encrypt que falló silenciosamente. Un visitante que ve una advertencia de certificado expirado se va. No hace clic en “Avanzado > Proceder de todos modos”.
El monitoreo de certificados SSL verifica la cadena de certificación, la fecha de expiración y el estado de revocación. Configura las alertas de expiración para que se activen 30, luego 14, luego 7 días antes. Quieres tiempo para rotar el certificado sin una página de incidente.
4. Verificación Completa de Página con Navegador Real
Una respuesta 200 no es lo mismo que una página funcionando. Los sitios modernos dependen de paquetes JavaScript, scripts de terceros (análisis, pago, chat) y activos servidos por CDN. Cualquiera de esos puede fallar mientras el HTML sigue devolviendo 2xx.
Una verificación de monitoreo de página web con navegador real carga la página como lo haría Chrome, ejecuta el JavaScript y verifica que aparezcan elementos críticos del DOM. Esta es la verificación que detecta problemas de “el sitio parece roto” que verificaciones HTTP puras no capturan.
5. Verificación de Transacción Crítica
Para una app SaaS, la verificación más importante es “¿puede un usuario iniciar sesión?”. Para un sitio de comercio electrónico, es “¿puede un usuario completar una compra?”. Estos son flujos multi-paso que involucran una sesión, envío de formulario, llamada a API y página de confirmación final.
El monitoreo sintético para transacciones ejecuta un recorrido de usuario guionado en un horario (login, búsqueda, añadir al carrito, compra) y alerta si algún paso falla. EveryStep de Dotcom-Monitor te permite grabar estos flujos en un navegador real sin escribir código.
Si solo configuras una verificación más allá de la HTTP básica, que sea esta. El monitoreo de transacciones es la señal más cercana al ingreso real.
Elegir Intervalos y Ubicaciones para Monitoreo
De Dónde Verificar
Una única ubicación de monitoreo es un punto único de falla para tu monitoreo. Si tu único nodo está en Virginia y la región AWS us-east-1 tiene un problema regional, recibirás una falsa caída. Si tu nodo está en Virginia y el edge europeo de tu CDN está degradado, perderás una caída real.
La solución es realizar verificaciones distribuidas desde varias geografías. La red global de monitoreo de Dotcom-Monitor ejecuta verificaciones desde centros de datos en Norteamérica, Europa, Asia-Pacífico y Sudamérica.
Para un sitio pequeño, tres a cinco ubicaciones son suficientes. Elige una cerca de cada gran concentración de clientes, más una ubicación remota para detectar problemas de ruta de red. No pagues por 30 ubicaciones si tus clientes están todos en un solo país.
Una regla práctica: alerta cuando al menos dos ubicaciones reporten fallas dentro de una ventana de 30–60 segundos. Esa ventana equivale a aproximadamente dos ciclos consecutivos de 1 minuto, lo que filtra fallas transitorias en un solo nodo mientras detecta caídas reales rápidamente.
Con qué Frecuencia Verificar
La frecuencia de verificación equilibra costo y tiempo de detección. Los intervalos comunes:
- 1 minuto para páginas generadoras de ingresos (checkout, login, landers de tráfico pagado).
- 5 minutos para páginas principales de marketing y monitoreo de API.
- 15 minutos para páginas secundarias, herramientas internas y contenido de bajo tráfico.
Una verificación cada 5 minutos significa que una caída puede durar hasta 5 minutos antes de que te enteres. El costo de ese tiempo depende de cuánto ingreso genera la página afectada por minuto. La calculadora de disponibilidad de Dotcom-Monitor ayuda a dimensionar eso según tu SLA.
Las verificaciones de 1 minuto son más costosas (algunas herramientas cobran por verificación, otras por monitor). Para la mayoría de sitios pequeños, cobertura de 1 minuto en los tres caminos de ingresos y de 5 minutos en el resto es la decisión correcta.
Enrutamiento de Alertas Que Realmente Se Notan
El modo de falla aquí es la fatiga por alertas. Si tu monitoreo te alerta por cada pequeña falla, terminas ignorándolo y la caída real llega con una alerta silenciada. Algunas reglas prácticas:
Establece una política N de M. No alertes por una sola verificación fallida. Alerta cuando 2 de 3 (o 3 de 5) verificaciones consecutivas fallan. Esto elimina la mayoría de falsos positivos sin retrasar significativamente los reales.
Separa críticas de no críticas. La alerta de “checkout roto” debe sonar en tu teléfono a las 3 a.m. La alerta “página de marketing lenta” puede ir a un canal de chat durante horario laboral. Configura rutas separadas para cada una. La funcionalidad de alertas de Dotcom-Monitor soporta canales por monitor, cadenas de escalamiento y reglas de horarios laborales y no laborables.
Usa ventanas de supresión durante mantenimiento programado. Si vas a lanzar una versión y esperas un corte de 30 segundos, suprime alertas en los monitores afectados durante ese tiempo. No los desactives. La supresión debe expirar automáticamente.
Escala tras un retraso. Si el primer contacto no responde en 5 minutos, alerta al segundo. Después de 15 minutos, alerta al tercero. Sacar alguien de una reunión está bien. Perder una caída porque el primer respondedor estaba en un vuelo, no lo está.
Añade un dead man’s switch. Una herramienta de monitoreo que se queda silenciosa no es igual que un sitio saludable. Ejecuta una verificación de latido que te alerte si ninguna verificación ha reportado en 10 minutos. Esto detecta cuando el proveedor de monitoreo tiene un mal día.
Clasifica tus canales. Las alertas críticas deberían ir por teléfono o SMS, no email. El email sirve para resúmenes diarios e informes de incumplimiento de SLA 99.95%. Un canal Slack para advertencias está bien. Una llamada a las 3 a.m. debe significar que realmente algo anda mal.
Qué Hacer Cuando Se Dispara una Alerta
Una alerta es el inicio de un proceso, no el fin. Escribe qué hacer para tus tres tipos de alerta más probables antes de que ocurran. El objetivo es eliminar la toma de decisiones durante los primeros cinco minutos de un incidente.
Un runbook mínimo para una alerta de “sitio caído”:
- Abre el panel de monitoreo. Confirma la falla desde al menos dos ubicaciones antes de tratarla como real.
- Revisa la implementación más reciente. Si salió una versión en los últimos 30 minutos, revierte primero e investiga después.
- Verifica las fuentes externas: página de estado del proveedor DNS, página de estado CDN, página de estado del hosting. La mayoría de las caídas son problemas de terceros.
- Si es un problema de terceros, publica en tu propia página de estado y deja de intentar arreglarlo por tu lado.
- Si es tu problema, revisa los logs de la aplicación para encontrar picos de error, localiza el servicio fallido y reinícialo o revierte la versión.
- Tras la resolución, realiza un post-mortem de 15 minutos. Anota qué falló, cómo lo notaste y qué lo arregló. No recordarás los detalles en tres meses.
Modos Comunes de Fallo y Cómo Se Ven
Una guía de campo corta para que la alerta no sea la primera vez que ves el síntoma.
Certificado SSL expirado. Todas las verificaciones HTTPS fallan simultáneamente en todas las ubicaciones. La verificación HTTP aún funciona (puerto 80) si la sirves. Solución: rota el certificado. Prevención: alertas de expiración SSL a T-30, T-14 y T-7 días.
Caída del proveedor DNS. Algunas verificaciones fallan, otras pasan, sin un patrón claro por región. Tu TTL determina cuánto durará la caída desde la perspectiva del usuario. Solución: cambia de proveedor o espera. Prevención: un proveedor DNS secundario en el mismo dominio.
Problema regional de CDN. Verificaciones desde una zona geográfica fallan mientras otras pasan. Las páginas devuelven 5xx o quedan colgadas. Solución: purga la caché CDN o cambia al origen. Prevención: monitorea desde múltiples regiones para detectar esto en minutos, no horas.
Paquete JavaScript roto por implementación. Las verificaciones HTTP pasan (200 OK). Las verificaciones con navegador real fallan porque faltan elementos DOM. Síntoma: clientes envían emails diciendo “el botón no funciona”. Solución: revertir. Prevención: verificaciones con navegador real en páginas críticas y bloqueo de despliegue hasta que la verificación sintética pase.
Timeout de script de terceros. La página carga, pero lento. Verificaciones de transacciones fallan intermitentemente en el paso que depende del script (widget de chat, análisis, pruebas A/B). Solución: carga el script async, establece timeouts, elimínalo si no es esencial. Prevención: alertas por tiempo de carga en páginas críticas.
Cómo Elegir la Herramienta Adecuada
El mercado tiene docenas de opciones. UptimeRobot y Pingdom manejan bien el uptime básico. StatusCake, Site24x7 y Uptrends compiten en precio y funcionalidad. Datadog Synthetics y New Relic Synthetics encajan en equipos que ya usan esas plataformas para APM.
Las preguntas a hacer, en orden:
- ¿Realiza verificaciones desde las geografías donde realmente viven mis clientes?
- ¿Soporta verificaciones con navegador real y transacciones multi-paso, no solo HTTP?
- ¿La alerta se integra con los canales que realmente monitoreo (SMS, teléfono, PagerDuty, Slack)?
- ¿Ofrece una página de estado pública a la que mis clientes puedan suscribirse?
- ¿Cuál es el precio para intervalos de 1 minuto para las verificaciones críticas que necesito?
Dotcom-Monitor cubre todo el stack desde una sola plataforma: uptime, sintético, monitoreo de aplicaciones web, API, más la capa de alertas y reportes de uptime y SLA encima. Consulta precios para ver cómo se ve una cobertura multi-verificación a 1 minuto para un sitio de tu tamaño.
Qué Hacer Esta Semana
Configura verificaciones HTTP(S) en tus tres páginas principales generadoras de ingresos desde al menos tres ubicaciones geográficas a intervalos de 1 minuto. Añade monitoreo de expiración SSL. Añade una verificación con navegador real en tu transacción más importante (login o checkout). Configura alertas SMS con una política de fallo 2 de 3. Escribe qué harás si se dispara cada una.
