{"id":34065,"date":"2026-06-05T13:31:42","date_gmt":"2026-06-05T13:31:42","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-availability-monitoring\/"},"modified":"2026-06-05T13:38:21","modified_gmt":"2026-06-05T13:38:21","slug":"website-availability-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/website-availability-monitoring\/","title":{"rendered":"Monitoreo de Disponibilidad del Sitio Web: Una Gu\u00eda Pr\u00e1ctica para Permanecer En L\u00ednea"},"content":{"rendered":"
\"Dashboard
El monitoreo de disponibilidad realiza verificaciones continuas desde m\u00faltiples regiones y enruta alertas antes de que los clientes las noten.<\/figcaption><\/figure>\n

Un propietario del sitio usualmente descubre que su sitio est\u00e1 ca\u00eddo de la misma manera que los clientes: a trav\u00e9s de un correo de soporte, una notificaci\u00f3n de contracargo o una ca\u00edda en el proceso de compra que aparece en el panel de an\u00e1lisis a la ma\u00f1ana siguiente. Para ese momento, el incidente tiene horas de antig\u00fcedad y los ingresos se han perdido.<\/p>\n

El monitoreo de disponibilidad del sitio web es la pr\u00e1ctica de detectar fallos antes de que eso suceda. Pero “\u00bfest\u00e1 el sitio activo?” resulta ser una pregunta m\u00e1s dif\u00edcil de lo que parece. Un sitio puede devolver un 200 OK mientras el bot\u00f3n de compra est\u00e1 roto. Un sitio puede ser accesible desde EE.UU. y estar ca\u00eddo en Europa. Un sitio puede estar t\u00e9cnicamente en l\u00ednea y a\u00fan fallar para los usuarios porque el proveedor de DNS est\u00e1 agotando el tiempo de respuesta o el certificado SSL expir\u00f3 a las 2 a.m.<\/p>\n

Esta gu\u00eda cubre el lado operativo del monitoreo de disponibilidad del sitio web: qu\u00e9 verificar, de d\u00f3nde verificar, con qu\u00e9 frecuencia y qu\u00e9 hacer cuando se dispara una alerta. Est\u00e1 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\u00ede una alerta.<\/p>\n

Qu\u00e9 Significa Realmente “Disponible”<\/h2>\n

Hay una brecha entre “el servidor respondi\u00f3” y “un usuario pudo comprar algo”. El monitoreo de disponibilidad vive en esa brecha.<\/p>\n

Una simple verificaci\u00f3n de tiempo activo<\/a> hace ping a tu URL y busca un c\u00f3digo de estado 200. Ese es el nivel b\u00e1sico. Detecta fallas catastr\u00f3ficas (servidor ca\u00eddo, DNS roto, red inalcanzable) y no detecta fallas m\u00e1s sutiles: un procesador de pagos que da error 500 en la compra, una configuraci\u00f3n CDN que sirve una p\u00e1gina en blanco, un error de JavaScript que rompe el bot\u00f3n de inicio de sesi\u00f3n en Safari.<\/p>\n

El monitoreo de disponibilidad real apila verificaciones unas sobre otras para que “el sitio est\u00e9 activo” signifique que un usuario real, en un navegador real, en una ubicaci\u00f3n real, pueda hacer lo que vino a hacer. El glosario de Dotcom-Monitor tiene una definici\u00f3n m\u00e1s completa de disponibilidad del sitio web<\/a> si quieres la versi\u00f3n formal.<\/p>\n

Un patr\u00f3n com\u00fan de fallo real:<\/strong> una implementaci\u00f3n el viernes por la noche introduce una nueva etiqueta de an\u00e1lisis. El HTML sigue devolviendo 200 OK desde todas las regiones, por lo que una herramienta b\u00e1sica de uptime reporta verde todo el fin de semana. El lunes por la ma\u00f1ana, el soporte est\u00e1 abrumado con tickets porque la etiqueta de terceros bloquea el manejador de env\u00edo del formulario de compra en Safari. Una verificaci\u00f3n con navegador real en la p\u00e1gina de checkout habr\u00eda detectado la falla dentro de un intervalo de sondeo. Una simple verificaci\u00f3n HTTP no.<\/p><\/blockquote>\n

Por Qu\u00e9 Importa el Monitoreo de Disponibilidad<\/h2>\n

El costo del tiempo de inactividad var\u00eda mucho seg\u00fan el negocio, pero las categor\u00edas de da\u00f1o son consistentes: transacciones perdidas, SLAs incumplidos, da\u00f1o a la reputaci\u00f3n de la marca y penalizaciones en ranking de b\u00fasqueda por rastreadores que encuentran p\u00e1ginas de error durante una ca\u00edda prolongada, adem\u00e1s del costo interno del manejo de incidentes de emergencia.<\/p>\n

Para sitios de comercio electr\u00f3nico, incluso unos minutos de inactividad durante el tr\u00e1fico pico pueden significar miles de d\u00f3lares en pedidos perdidos. Para proveedores SaaS, una sola ca\u00edda prolongada puede activar cr\u00e9ditos de SLA<\/a> y erosionar la confianza del cliente que tom\u00f3 a\u00f1os construir. Para sitios de medios y publicaciones, el tiempo de inactividad en una noticia de \u00faltima hora es tr\u00e1fico que simplemente nunca regresa.<\/p>\n

El monitoreo de disponibilidad reduce la ventana entre que algo sale mal y alguien lo soluciona. Ese tiempo medio hasta la detecci\u00f3n (MTTD) es a menudo la palanca m\u00e1s grande para reducir el impacto total de un incidente.<\/p>\n

C\u00f3mo Funciona el Monitoreo de Disponibilidad<\/h2>\n

La mayor\u00eda del monitoreo de disponibilidad depende de verificaciones sint\u00e9ticas: solicitudes autom\u00e1ticas enviadas desde nodos de monitoreo distribuidos por el mundo. Estas verificaciones se realizan a intervalos regulares \u2014 desde cada pocos segundos hasta cada pocos minutos \u2014 y registran si el objetivo respondi\u00f3 correctamente dentro de un tiempo aceptable.<\/p>\n

Una verificaci\u00f3n t\u00edpica involucra un agente de monitoreo en una ubicaci\u00f3n geogr\u00e1fica espec\u00edfica enviando una solicitud HTTP a tu URL, y luego evaluando la respuesta contra un conjunto de reglas. \u00bfDevolvi\u00f3 un c\u00f3digo de estado 2xx<\/a>, o provoc\u00f3 un error cr\u00edtico del servidor? \u00bfEl tiempo de respuesta estuvo bajo el umbral? \u00bfLa p\u00e1gina conten\u00eda el contenido esperado? \u00bfTodos los recursos de la p\u00e1gina se cargaron con \u00e9xito?<\/p>\n

Cuando una verificaci\u00f3n 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\u00edan falsas alarmas constantes. Solo cuando las fallas se confirman en m\u00faltiples ubicaciones, el sistema escala a una alerta.<\/p>\n

C\u00f3mo Monitorear el Tiempo Activo del Sitio Web: Las Cinco Verificaciones Que Todo Sitio Necesita<\/h2>\n

El consejo est\u00e1ndar es “monitorea el tiempo activo”. Eso pierde la mayor\u00eda de las formas de fallo. A continuaci\u00f3n, las cinco tipos de chequeos que detectan los fallos que los propietarios de sitios realmente ven en producci\u00f3n.<\/p>\n

\"Diagrama
Cada capa detecta fallos que la capa inferior no puede ver.<\/figcaption><\/figure>\n

1. Verificaci\u00f3n de Estado HTTP(S)<\/h3>\n

La verificaci\u00f3n b\u00e1sica. Se accede a una URL, se espera una respuesta 2xx, se alerta cualquier otro resultado. Config\u00farala para la p\u00e1gina principal, la p\u00e1gina de precios, el checkout y cualquier p\u00e1gina de aterrizaje relacionada con tr\u00e1fico pagado. Esto detecta ca\u00eddas graves y fallos en el apret\u00f3n de manos SSL.<\/p>\n

Ejecuta la verificaci\u00f3n desde m\u00faltiples ubicaciones. Una verificaci\u00f3n desde un \u00fanico centro de datos en EE.UU. reportar\u00e1 “activo” mientras clientes en S\u00eddney ven un error de CloudFront.<\/p>\n

2. Verificaci\u00f3n de Resoluci\u00f3n DNS<\/h3>\n

Un sitio que no puede resolverse es un sitio que no existe, aunque el servidor est\u00e9 saludable. Los problemas de DNS usualmente se deben a ca\u00eddas del proveedor (Route 53 ha tenido algunas notables), dominios expirados o problemas de propagaci\u00f3n tras un cambio de registro.<\/p>\n

Una verificaci\u00f3n de monitoreo DNS<\/a> resuelve tu dominio contra varios resolutores p\u00fablicos y alerta cuando la respuesta cambia inesperadamente o la consulta falla por completo.<\/p>\n

3. Validez del Certificado SSL<\/h3>\n

Los certificados expiran. Se revocan. Se configuran mal durante una renovaci\u00f3n de Let’s Encrypt que fall\u00f3 silenciosamente. Un visitante que ve una advertencia de certificado expirado se va. No hace clic en “Avanzado > Proceder de todos modos”.<\/p>\n

El monitoreo de certificados SSL<\/a> verifica la cadena de certificaci\u00f3n, la fecha de expiraci\u00f3n y el estado de revocaci\u00f3n. Configura las alertas de expiraci\u00f3n para que se activen 30, luego 14, luego 7 d\u00edas antes. Quieres tiempo para rotar el certificado sin una p\u00e1gina de incidente.<\/p>\n

4. Verificaci\u00f3n Completa de P\u00e1gina con Navegador Real<\/h3>\n

Una respuesta 200 no es lo mismo que una p\u00e1gina funcionando. Los sitios modernos dependen de paquetes JavaScript, scripts de terceros (an\u00e1lisis, pago, chat) y activos servidos por CDN. Cualquiera de esos puede fallar mientras el HTML sigue devolviendo 2xx.<\/p>\n

Una verificaci\u00f3n de monitoreo de p\u00e1gina web<\/a> con navegador real carga la p\u00e1gina como lo har\u00eda Chrome, ejecuta el JavaScript y verifica que aparezcan elementos cr\u00edticos del DOM. Esta es la verificaci\u00f3n que detecta problemas de “el sitio parece roto” que verificaciones HTTP puras no capturan.<\/p>\n

5. Verificaci\u00f3n de Transacci\u00f3n Cr\u00edtica<\/h3>\n

Para una app SaaS, la verificaci\u00f3n m\u00e1s importante es “\u00bfpuede un usuario iniciar sesi\u00f3n?”. Para un sitio de comercio electr\u00f3nico, es “\u00bfpuede un usuario completar una compra?”. Estos son flujos multi-paso que involucran una sesi\u00f3n, env\u00edo de formulario, llamada a API y p\u00e1gina de confirmaci\u00f3n final.<\/p>\n

El monitoreo sint\u00e9tico<\/a> para transacciones ejecuta un recorrido de usuario guionado en un horario (login, b\u00fasqueda, a\u00f1adir al carrito, compra) y alerta si alg\u00fan paso falla. EveryStep de Dotcom-Monitor te permite grabar estos flujos en un navegador real sin escribir c\u00f3digo<\/a>.<\/p>\n

Si solo configuras una verificaci\u00f3n m\u00e1s all\u00e1 de la HTTP b\u00e1sica, que sea esta.<\/strong> El monitoreo de transacciones es la se\u00f1al m\u00e1s cercana al ingreso real.<\/p><\/blockquote>\n

Elegir Intervalos y Ubicaciones para Monitoreo<\/h2>\n

De D\u00f3nde Verificar<\/h3>\n

Una \u00fanica ubicaci\u00f3n de monitoreo es un punto \u00fanico de falla para tu monitoreo. Si tu \u00fanico nodo est\u00e1 en Virginia y la regi\u00f3n AWS us-east-1 tiene un problema regional, recibir\u00e1s una falsa ca\u00edda. Si tu nodo est\u00e1 en Virginia y el edge europeo de tu CDN est\u00e1 degradado, perder\u00e1s una ca\u00edda real.<\/p>\n

La soluci\u00f3n es realizar verificaciones distribuidas desde varias geograf\u00edas. La red global de monitoreo<\/a> de Dotcom-Monitor ejecuta verificaciones desde centros de datos en Norteam\u00e9rica, Europa, Asia-Pac\u00edfico y Sudam\u00e9rica.<\/p>\n

Para un sitio peque\u00f1o, tres a cinco ubicaciones son suficientes. Elige una cerca de cada gran concentraci\u00f3n de clientes, m\u00e1s una ubicaci\u00f3n remota para detectar problemas de ruta de red. No pagues por 30 ubicaciones si tus clientes est\u00e1n todos en un solo pa\u00eds.<\/p>\n

Una regla pr\u00e1ctica: alerta cuando al menos dos ubicaciones reporten fallas dentro de una ventana de 30\u201360 segundos. Esa ventana equivale a aproximadamente dos ciclos consecutivos de 1 minuto, lo que filtra fallas transitorias en un solo nodo mientras detecta ca\u00eddas reales r\u00e1pidamente.<\/p><\/blockquote>\n

Con qu\u00e9 Frecuencia Verificar<\/h3>\n

La frecuencia de verificaci\u00f3n equilibra costo y tiempo de detecci\u00f3n. Los intervalos comunes:<\/p>\n