La mayoría de los equipos se enteran de que su sitio está caído por un correo de un cliente, una publicación en redes sociales o un panel de ventas que muestra un nivel plano silenciosamente. Para cuando una persona se da cuenta, la caída ha estado ocurriendo durante el tiempo que alguien tardó en quejarse, y el daño comenzó mucho antes.
El monitoreo de tiempo de actividad cierra esa brecha con un mecanismo simple: comprobaciones automatizadas realizadas en tu sitio según un horario, desde fuera de tu propia red, que envían una alerta en el momento en que una respuesta es incorrecta o no llega. La configuración toma minutos. Que diga la verdad requiere tomar algunas decisiones que la mayoría de los tutoriales omiten, porque un monitor con configuraciones predeterminadas pierde fallos reales y genera falsas alarmas.
Esta guía recorre esas decisiones en siete pasos: definir qué significa “activo”, escoger tipos de comprobación, establecer la frecuencia, verificar desde múltiples ubicaciones, configurar alertas, filtrar falsos positivos y reportar tiempo de actividad contra un SLA.
Una idea une los siete pasos: trata al monitor como una pila de verdad, no como una única comprobación. DNS prueba que el nombre resuelve, TCP prueba que el servicio es accesible, TLS prueba que los navegadores confiarán en él, HTTP prueba que la aplicación responde, la validación de contenido prueba que la página correcta se renderizó, y el monitoreo de recorrido prueba que un visitante puede completar la tarea. Construye la pila de afuera hacia adentro, y cada alerta nombra la capa que falló en lugar de encogerse de hombros diciendo “sitio caído”.
Paso 1: Define Qué Significa “Activo” para Tu Sitio
La definición más perezosa de activo es “el servidor responde”. También es la que causa problemas. Un host puede responder ping mientras el proceso del servidor web está muerto. Un servidor web puede devolver HTTP 200 mientras sirve una página de mantenimiento, una plantilla parcialmente renderizada o el contenido de otra persona tras un secuestro de DNS. Ninguno de esos cuenta como activo para un visitante.
Es útil nombrar los tres estados de caída. Caída dura: el host no responde nada en absoluto. Caída suave: el servidor devuelve un 200 mientras sirve un error de base de datos, una plantilla en blanco o el contenido de otro tras un secuestro de DNS. Caída fantasma: tus servidores están saludables, pero un borde CDN roto o una falla de enrutamiento regional oculta el sitio a una parte de tu audiencia. Un monitor que solo detecta caída dura ignora los otros dos estados que ocurren con más frecuencia.
Así que antes de configurar cualquier cosa, escribe qué debe ser verdad para que tu sitio esté genuinamente disponible:
- El dominio resuelve a la dirección correcta, rápidamente.
- Las páginas críticas responden con un código de estado exitoso. Crítico significa la página principal más todas las páginas cuyo fallo cuesta dinero o confianza: carrito de compras, inicio de sesión, registro, endpoints clave de API.
- La respuesta contiene el contenido correcto. Una palabra clave o elemento que solo aparece cuando la página se renderizó correctamente, de modo que una plantilla de error servida con un 200 sigue fallando la comprobación.
- El certificado es válido y la respuesta llega dentro de un tiempo aceptable para un usuario.
Esa lista no es burocracia. Corresponde directamente a las capas donde las solicitudes fallan realmente, y las fallas ocurren en DNS, TCP, TLS y HTTP de maneras distintas. Una comprobación que solo teste un nivel no detecta los otros tres. La lista también define qué URLs monitorear: no todas las páginas, solo las que estén en tu definición.
Escrito para un sitio de ecommerce, el monitor de la página principal podría ser: devuelve 200 en menos de 3 segundos, contiene “Envío gratuito”, presenta un certificado con más de 14 días de validez, resuelve a través del CNAME esperado hacia el CDN. El monitor de checkout es más estricto: devuelve 200, contiene “Resumen de pedido”, falla si falta el script del proveedor de pago. Ambas URLs cuentan como activas, pero no merecen la misma definición.
Paso 2: Escoge Tus Tipos de Comprobación de Tiempo de Actividad
Con la definición escrita, elige comprobaciones que verifiquen cada parte. Cinco tipos de comprobaciones cubren casi todos los escenarios de tiempo de actividad, y cada uno puede mentir si se considera prueba del experiencia completa:
| Tipo de comprobación | Qué verifica | Qué detecta | Dónde puede inducir a error |
|---|---|---|---|
| HTTP(S) | Código de estado y contenido de respuesta de una URL | Errores del servidor, páginas de error servidas con 200, contenido erróneo o secuestrado | Un 200 puede llevar la plantilla equivocada o una página de error en caché |
| Ping (ICMP) | El host responde solicitudes echo | Fallas de red y a nivel del host, pérdida de paquetes, problemas de enrutamiento | Un host puede responder ICMP mientras que el servicio web o TLS están rotos |
| Puerto TCP | Un puerto específico acepta conexiones | Proceso de servicio caído en un host que aún responde al ping | Un puerto abierto prueba que hay un receptor, no que la aplicación detrás esté saludable |
| DNS | El dominio resuelve a los registros esperados | Dominios caducados, cambios erróneos de registros, fallas del proveedor DNS | Un resolver puede tener la respuesta correcta mientras otra región sirve registros obsoletos |
| Certificado SSL | Validez del certificado y días para el vencimiento | Certificados expirados o mal configurados que los navegadores bloquean | Un certificado válido no dice nada sobre el contenido servido detrás |
Comprobaciones HTTP y HTTPS
La comprobación fundamental. Solicita una URL, verifica el código de estado y, si está bien configurada, afirma que una palabra clave aparece en el cuerpo de la respuesta. Cualquier código fuera del rango de éxito, como los comunes códigos de estado 4xx y 5xx, se considera una falla. La afirmación de contenido separa “el servidor respondió” de “la página realmente cargó”: un 200 con una plantilla de error pasa una prueba ingenua y falla una comprobación de palabra clave.
Comprobaciones Ping (ICMP)
El monitoreo ping ICMP verifica que el host es accesible y mide latencia y pérdida de paquetes en el camino. Es barato, rápido y útil para el triaje a nivel de red. También es débil si es tu única comprobación, porque una máquina puede responder ping con su servidor web caído y algunas redes depriorizan o bloquean ICMP.
Comprobaciones de Puertos TCP
Una comprobación de puerto TCP confirma que un puerto específico acepta conexiones: 443 para tráfico web, 25 para correo, o cualquier puerto personalizado que tu aplicación use. Detecta la clásica falla intermedia donde el host está bien y el ping funciona, pero el proceso de servicio se bloqueó y el puerto rechaza conexiones.
Comprobaciones DNS
El monitoreo DNS verifica que tu dominio resuelve a los registros que esperas y mide cuánto tarda la resolución. Cuando DNS falla, por registro expirado, cambio incorrecto o falla del proveedor, tu sitio está caído para todos aunque tus servidores estén saludables. Es el modo de falla que los equipos olvidan cubrir más a menudo.
Comprobaciones de Certificado SSL
El monitoreo de certificado SSL rastrea fechas de expiración y problemas de cadena de validación. Un certificado expirado es funcionalmente una caída: los navegadores muestran una advertencia de pantalla completa que la mayoría de los visitantes no pasarán. Con la duración de los certificados cada vez más corta, seguir su expiración con recordatorios de calendario ya no funciona, así que deja que un monitor cuente días y alerte a 30, 14 y 7 días.
Una pila inicial sensata: comprobaciones HTTP(S) con afirmaciones de contenido en cada página crítica, más comprobaciones DNS y de certificado en el dominio, con ping y TCP añadidos donde ayudan a diferenciar problemas de red de problemas de aplicación.
Paso 3: Establece la Frecuencia Correcta de Comprobación
Tu intervalo de comprobación es el límite superior para la velocidad de detección. Una caída que comienza segundos después de una comprobación exitosa durará casi todo el intervalo antes de que la siguiente comprobación pueda detectarla, y luego la verificación y alerta añaden tiempo adicional.
Compáralo contra el objetivo de disponibilidad y la demora se vuelve costosa. Un objetivo mensual del 99.9% permite cerca de 43 minutos de inactividad. Un intervalo de cinco minutos puede consumir más de una décima parte de ese presupuesto antes que alguien sepa que hay un problema, lo que es parte del verdadero costo de la inactividad. Trabájalo como un presupuesto de detección: decide cuánto porcentaje del tiempo permitido mensual quieres gastar antes que la primera persona se entere. Permitiendo el 10% de un presupuesto 99.9% se obtienen unos 4 minutos, lo que descarta un intervalo de cinco minutos antes de que la escalada entre en la conversación. En términos de ingresos, un sitio que gana $5,000 por hora pierde más de $400 en un hueco ciego de cinco minutos. Como regla práctica:
- Cada minuto para objetivos críticos de ingresos: checkout, login, APIs de pago, cualquier cosa bajo un SLA formal.
- Cada 3 a 5 minutos para sitios de marketing estándar y páginas de contenido.
- Cada 15 a 60 minutos para herramientas internas, entornos staging y servicios de bajo impacto.
Las comprobaciones HTTP livianas son lo suficientemente económicas para ejecutarse frecuentemente en todas partes. Las comprobaciones basadas en navegador más pesadas suelen ejecutarse en un horario más lento, superpuestas sobre comprobaciones rápidas básicas. Para un tratamiento más profundo de cómo interactúan intervalo y geografía, consulta esta guía sobre frecuencia y ubicaciones de monitoreo.
Paso 4: Monitorea Desde Múltiples Ubicaciones
Una sola ubicación de monitoreo te da un solo punto de vista, y eso genera dos modos de falla a la vez. Pierdes caídas que solo afectan algunas regiones, como un borde CDN defectuoso, un error de geo-DNS o un problema de enrutamiento entre un ISP y tu host. Y heredas cada fallo de la red de esa ubicación como una falsa alarma.
Elige ubicaciones que coincidan con dónde están tus usuarios. Un sitio que sirve Norteamérica y Europa debe ser monitoreado desde ambas costas de EE.UU. y al menos una ciudad europea, no desde un solo centro de datos en un país. Plataformas con redes globales de monitoreo, Dotcom-Monitor entre ellas, te permiten seleccionar puntos de control por continentes para que el monitor vea lo que tu audiencia real ve.
Varias ubicaciones también permiten la verificación cruzada, de la que depende el paso 6: cuando una ubicación reporta una falla, la plataforma revisa desde otras antes de declarar el sitio caído. Y cuando un incidente es real, el patrón geográfico es tu primer diagnóstico. Fallos desde todas las ubicaciones apuntan a origen, DNS global, certificado o una mala implementación. Fallos desde una región indican un borde CDN, enrutado regional o proveedor local. HTTP pasa en todas partes pero falla la afirmación de contenido indica una plantilla equivocada o página de error en caché. Cada patrón es un ticket distinto para un proveedor distinto, por eso es valioso entender la división por ubicación antes de reiniciar algún servidor.
Paso 5: Configura Alertas y Escalación
La detección solo importa si la persona correcta actúa. Antes del primer incidente, decide quién recibe qué fallos, por qué canal y en qué orden:
- Haz que el canal corresponda a la gravedad. El correo electrónico está bien para un certificado que expira en 30 días. Una caída dura confirmada debe llegar al teléfono, SMS o a la herramienta de guardia que tu equipo ya vigila. La entrega de alertas puede realizarse por correo, SMS, teléfono e integraciones con Slack, Teams y PagerDuty.
- Escala si no hay respuesta. La primera alerta va al ingeniero de turno. Si no hay reconocimiento en un número establecido de minutos, pasa automáticamente al siguiente nivel. Una alerta que nadie vio es una alerta que nunca pasó.
- Alerta por degradación, no solo por caída. Un tiempo de respuesta que se triplica suele ser preludio a una caída. Un umbral de advertencia en rendimiento te da tiempo que una alerta binaria de activo/inactivo nunca dará.
- Silencia mantenimientos planificados. Las ventanas programadas evitan que despliegues despierten a alguien, protegiendo la credibilidad de cada alerta que sí sucede.
Escribe la alerta como un contrato: qué falló, desde dónde, cuánto tiempo, y qué cambió desde la última comprobación exitosa. “Fallo en la comprobación de contenido de checkout desde Frankfurt y Londres en dos intentos consecutivos; DNS y TLS pasaron; no se encontró ‘Resumen de pedido’; último éxito 09:41 UTC” da al responsable una hipótesis inicial. Un simple “sitio caído” solo da una alarma.
Para un conjunto más completo de reglas sobre umbrales, enrutamiento y escalación, consulta estas prácticas de alertas para monitoreo web.
Paso 6: Elimina los Falsos Positivos
Los falsos positivos son cómo mueren los programas de monitoreo. Unas pocas alertas a las 3 a.m. que resultan ser nada y el ingeniero de turno comienza a ignorar la única real. La mayoría de falsas alarmas provienen de cuatro fuentes: fallas de red transitorias entre el punto de control y el sitio, tiempos de espera fijados más estrictos que el comportamiento normal, problemas en la ubicación de monitoreo y despliegues que el monitor no sabe.
Cada una tiene una contramedida directa:
- Confirma desde una segunda ubicación antes de alertar. Una comprobación fallida debe provocar una reverificación inmediata desde otros puntos, no una alerta. En Dotcom-Monitor, una ubicación en desacuerdo obliga a comprobaciones desde todas las ubicaciones seleccionadas, para que un punto defectuoso no despierte solo a tu equipo.
- Configura tiempos de espera basados en datos, no esperanzas. Usa umbrales basados en los tiempos reales que tu sitio muestra, con margen, para que una página lenta pero funcional sea una advertencia de rendimiento y no una falsa caída.
- Valida contenido, no solo conectividad. Las afirmaciones de palabra clave tienen doble función: detectan fallos suaves que un código de estado no muestra y evitan que un monitor llame caída a una página si el único problema es un widget lento de terceros, porque la comprobación apunta a lo que debe renderizarse, no a todo lo que podría.
- Pon despliegues en el calendario. Las ventanas de mantenimiento son la solución más barata para falsos positivos.
Luego tria el ruido restante en tres cubetas en una revisión semanal: mal punto de vista, mal umbral o mala definición de activo. Un mal punto de vista consigue confirmación cruzada. Un mal umbral se ajusta con los tiempos reales de respuesta. Una mala definición se afina con una afirmación de contenido más precisa. Una alerta que no entra en ninguno de los tres sigue generando ruido hasta entenderla, porque esconderla con un intervalo más largo solo retrasa el incidente real.
Paso 7: Mide el Tiempo de Actividad Contra Tu SLA
Cada resultado de comprobación alimenta un registro permanente de disponibilidad, y ese registro es lo que convierte el monitoreo de un detector de humo en evidencia. Los objetivos de tiempo de actividad suenan abstractos hasta que los traduces a minutos:
| Objetivo de tiempo de actividad | Tiempo de inactividad permitido por mes de 30 días | Tiempo de inactividad permitido por año |
|---|---|---|
| 99% | 7.2 horas | Aproximadamente 3.7 días |
| 99.9% (“tres nueves”) | 43.2 minutos | Aproximadamente 8.8 horas |
| 99.95% | 21.6 minutos | Aproximadamente 4.4 horas |
| 99.99% (“cuatro nueves”) | 4.3 minutos | Aproximadamente 53 minutos |
La aritmética explica el consejo previo: con cuatro nueves, un intervalo de comprobación de cinco minutos puede perder más inactividad que todo el presupuesto mensual. Pasa tus propios objetivos por un calculador de disponibilidad para ver qué promete tu SLA en minutos.
Mantén el registro independiente. Si tu host o CDN promete un SLA, tu reclamo de créditos depende de datos medidos externamente por ti, no del estado del proveedor. Mantén esa evidencia simple y exportable: marca de tiempo, ubicación del punto de control, IP resuelta, resultado TLS, estado HTTP, tiempo de respuesta y la afirmación fallida. Una captura de pantalla de una página de estado es un argumento; un historial de comprobaciones con ubicación es evidencia, ya sea para reclamar créditos o para apoyar tu propia página pública de estado. Los informes programados de tiempo de actividad y SLA pueden enviar ese registro automáticamente a las bandejas de entrada de interesados, segregados por comprobación y ubicación. La segregación importa: un promedio global saludable puede ocultar una región que estuvo caída todo el martes.
Más Allá del Tiempo de Actividad: Monitorea Recorridos Completos de Usuario
Todo lo anterior responde a una pregunta: ¿el sitio es accesible y responde correctamente? No puede decirte si un visitante puede buscar en el catálogo, añadir al carrito, pagar o iniciar sesión, porque esos flujos abarcan múltiples páginas, scripts y servicios de terceros que una comprobación de URL sola nunca toca.
Para equipos de marketing, el recorrido que vale la pena scriptar es el que prometen tus campañas. Si la búsqueda pagada envía visitantes a “Iniciar Prueba Gratis”, el script debe cargar la página de destino, hacer clic en el CTA, llenar el formulario con datos seguros de prueba y confirmar el estado de agradecimiento. Cuando ese camino se rompe mientras la campaña está activa, el tiempo de actividad de la página principal es una métrica vana.
Esa es la tarea del monitoreo sintético: sesiones con navegador real, scriptadas, que recorren tus viajes críticos paso a paso y señalan el paso exacto que falló. Con un grabador como EveryStep, un flujo de checkout o login se convierte en un script monitoreado repetible sin programar. Una vez que los siete pasos aquí estén sólidos, el monitoreo a nivel de transacción es la siguiente capa natural.
Conclusión
Monitorear bien el tiempo de actividad del sitio web significa construir la pila de verdad, no marcar una casilla. Define activo en términos de negocio y nombra qué estado de caída estás protegiendo. Cubre cada capa que cruza una solicitud con comprobaciones HTTP, ping, TCP, DNS y certificado, y conoce dónde cada una puede inducir a error. Ejecútalas dentro de un presupuesto de detección que tu SLA pueda pagar. Comprueba desde donde están tus usuarios. Escribe alertas que lleven una hipótesis, escala si hay silencio, confirma antes de alertar y guarda un registro independiente y exportable de cuál fue realmente tu disponibilidad, por región y por comprobación.
Configurado así, un monitor de tiempo de actividad deja de ser una casilla para marcar y se convierte en el primer sistema en saber de un problema, minutos antes que tus clientes. Esa ventaja es todo el sentido.
Comienza a Monitorear Tu Tiempo de Actividad en Minutos
Configura comprobaciones HTTP, ping, TCP, DNS y SSL desde una red global de monitoreo con Dotcom-Monitor uptime monitoring, luego conecta las alertas que tu equipo de guardia realmente confiará. Comienza una prueba gratuita.
