{"id":34142,"date":"2026-06-12T01:22:41","date_gmt":"2026-06-12T01:22:41","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-monitoring-alerts\/"},"modified":"2026-06-12T13:29:30","modified_gmt":"2026-06-12T13:29:30","slug":"alertas-de-monitoreo-de-sitios-web","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/alertas-de-monitoreo-de-sitios-web\/","title":{"rendered":"Alertas de Monitoreo de Sitios Web – Maximiza el Tiempo de Actividad y Reduce el Ruido"},"content":{"rendered":"

Actualizado en junio de 2026 \u00b7 Lectura de 11 minutos<\/em><\/p>\n

\"Ingeniero
El objetivo no es m\u00e1s alertas. Son menos alertas que cada una signifique algo.<\/figcaption><\/figure>\n

<\/p>\n

Pregunta a cualquier ingeniero de guardia sobre su monitoreo y te dir\u00e1 lo mismo: las alertas no son el problema. El ruido s\u00ed lo es. Un stack t\u00edpico dispara en cada muestra lenta, cada pico en una sola ubicaci\u00f3n, cada chequeo dependiente que falla cuando un servicio upstream se rompe. Despu\u00e9s de unas semanas de eso, la gente deja de leer las alertas. Y la noche que ocurre una falla real, cae en el mismo canal silenciado que 200 falsos positivos.<\/p>\n

As\u00ed es como la fatiga de alertas incrementa el Tiempo Promedio para la Resoluci\u00f3n. La detecci\u00f3n nunca fue el cuello de botella. La se\u00f1al qued\u00f3 enterrada. Esta gu\u00eda trata sobre construir alertas de monitoreo para sitios web que solo se activen cuando la experiencia del usuario est\u00e9 realmente comprometida, para que tu equipo conf\u00ede lo suficiente en ellas para actuar cuando lo hacen. Cubriremos l\u00f3gica de confirmaci\u00f3n, niveles de escalada, supresi\u00f3n consciente de dependencias y matem\u00e1ticas de umbrales, con los ajustes exactos que separan una rotaci\u00f3n de guardia tranquila de un pager que nadie atiende.<\/p>\n

Por qu\u00e9 la mayor\u00eda de las alertas son ruido, no se\u00f1al<\/h2>\n

Una alerta de monitoreo tiene un solo trabajo: decirle a un humano que algo est\u00e1 mal y necesita arreglarlo. La mayor\u00eda de las alertas fallan en esa tarea mediante tres patrones comunes, y cada uno tiene una soluci\u00f3n clara.<\/p>\n

Los falsos positivos en una sola ubicaci\u00f3n son los m\u00e1s frecuentes. Un agente de monitoreo en Frankfurt sufre un peque\u00f1o problema de red transitorio, la verificaci\u00f3n falla, la alerta se dispara, y tu sitio nunca estuvo ca\u00eddo para un solo usuario real. Ejecutar monitoreo de disponibilidad desde un solo lugar hace que un porcentaje de tus p\u00e1ginas fallen por p\u00e9rdida de paquetes entre tu monitor y tu origen, no por cortes reales.<\/p>\n

Los umbrales variables (flapping) vienen despu\u00e9s. Configuras una alerta de tiempo de respuesta en 2,000 ms porque parec\u00eda lento. Pero tu p95 (el tiempo de respuesta que ve el 5 % m\u00e1s lento de tus solicitudes) ya ronda los 1,800 ms durante tr\u00e1fico pico, as\u00ed que la alerta se dispara cada tarde, se limpia sola y se dispara de nuevo. Nadie act\u00faa porque no hay nada que hacer. El n\u00famero estaba mal, no el sitio.<\/p>\n

Y luego est\u00e1 la tormenta de alertas. La resoluci\u00f3n DNS falla para tu dominio. Ahora los chequeos de la p\u00e1gina principal fallan, los de inicio de sesi\u00f3n fallan, los del checkout fallan, los checks de API fallan y el del SSL tambi\u00e9n porque el monitor ni siquiera puede alcanzar el host. Una causa ra\u00edz, cuarenta alertas, todas dispar\u00e1ndose en el mismo minuto. El ingeniero de guardia tiene que leer las cuarenta para encontrar la que importa.<\/p>\n

Arregla esos tres patrones y eliminas la mayor parte del ruido. El resto de esta gu\u00eda explica c\u00f3mo hacerlo.<\/p>\n

Confirma un corte antes de avisar a alguien<\/h2>\n

El cambio con mayor impacto que puedes hacer es exigir confirmaci\u00f3n antes de que una alerta se dispare, y Dotcom-Monitor est\u00e1 dise\u00f1ado para aplicar exactamente eso. En lugar de enviar un aviso en la primera verificaci\u00f3n fallida, configuras las condiciones que una falla debe cumplir antes de que alguien se entere: acuerdo de m\u00e1s de una ubicaci\u00f3n y m\u00e1s de un chequeo fallido consecutivo. Ambos se configuran por monitor, as\u00ed decides cu\u00e1nta evidencia necesita cada chequeo antes de alertar.<\/p>\n

La confirmaci\u00f3n desde m\u00faltiples ubicaciones elimina el falso positivo en la fuente. Si un chequeo falla desde Frankfurt pero pasa desde Dallas, Londres y Singapur al mismo tiempo, el problema es la ruta a Frankfurt, no tu sitio. Una falla real ocurre en todas partes. Esa es la funci\u00f3n de la red global de monitoreo<\/a> de Dotcom-Monitor: cuando un chequeo falla, Dotcom-Monitor lo vuelve a verificar autom\u00e1ticamente desde m\u00e1s ubicaciones antes de enviar una alerta, as\u00ed que un pico regional \u00fanico nunca llega a tu rotaci\u00f3n de guardia. Solo escuchas fallos que coinciden en m\u00e1s de un punto de vista.<\/p>\n

La l\u00f3gica de fallos consecutivos maneja el glitch moment\u00e1neo. En el sistema de alertas<\/a> de Dotcom-Monitor configuras una alerta para que se active solo despu\u00e9s de que fallen dos o tres chequeos consecutivos, no el primero. A intervalos de un minuto, eso agrega uno o dos minutos de latencia en la detecci\u00f3n a cambio de reducir el ruido transitorio casi a cero. Para la mayor\u00eda de sitios ese intercambio vale la pena, y porque el filtro se configura por monitor, una p\u00e1gina de marketing puede tolerar una confirmaci\u00f3n m\u00e1s lenta que un endpoint de pago.<\/p>\n

La confirmaci\u00f3n agrega un peque\u00f1o retraso. Si manejas un sistema donde un segundo de ca\u00edda es verdaderamente catastr\u00f3fico, puedes aceptar m\u00e1s falsos positivos a cambio de detecci\u00f3n m\u00e1s r\u00e1pida. La mayor\u00eda de equipos no est\u00e1n en esa posici\u00f3n, y ese intercambio les da pagers tranquilos.<\/p>\n

Construye niveles de escalada que coincidan con la gravedad<\/h2>\n

Una alerta y una escalada no son lo mismo. La alerta es el hecho de que un chequeo fall\u00f3. La escalada es la regla que decide qui\u00e9n la recibe, por qu\u00e9 canal y qu\u00e9 pasa si nadie responde. El alertamiento plano, donde cada falla avisa a todos de la misma forma, es la ruta m\u00e1s r\u00e1pida hacia un equipo que ignora su pager.<\/p>\n

\"Camino
La gravedad decide el canal. El tiempo sin respuesta decide la escalada.<\/figcaption><\/figure>\n

<\/p>\n

Comienza clasificando las fallas por niveles de gravedad y asignando cada uno a un canal. El principio es simple: mientras m\u00e1s ruidoso el canal, mayor la barrera para usarlo.<\/p>\n

\n\n\n\n\n\n\n\n
Gravedad<\/th>\nEjemplo<\/th>\nCanal<\/th>\nQui\u00e9n responde<\/th>\n<\/tr>\n<\/thead>\n
Cr\u00edtica<\/td>\nCheckout o inicio de sesi\u00f3n ca\u00eddos, confirmado desde m\u00faltiples ubicaciones<\/td>\nSMS, tel\u00e9fono, PagerDuty<\/td>\nGuardia, inmediatamente<\/td>\n<\/tr>\n
Alta<\/td>\nP\u00e1gina principal lenta m\u00e1s all\u00e1 del p95 durante 10 minutos<\/td>\nSlack o Teams, @on-call<\/td>\nGuardia, en menos de una hora<\/td>\n<\/tr>\n
Baja<\/td>\nP\u00e1gina de marketing lenta, un activo con error 404<\/td>\nCorreo electr\u00f3nico resumen, panel de control<\/td>\nRevisado al siguiente d\u00eda h\u00e1bil<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Luego agrega escalada basada en el tiempo sobre la gravedad. Una alerta cr\u00edtica llega por Slack y al ingeniero de guardia al mismo tiempo. Si sigue abierta despu\u00e9s de diez minutos, se env\u00eda un segundo aviso por SMS. Despu\u00e9s de veinte, notifica al guardia secundario o al l\u00edder del equipo. Nadie tiene que recordar escalar a mano a las 3 AM, y una p\u00e1gina no respondida no se convierte en una falla ignorada.<\/p>\n

Dotcom-Monitor maneja esto con grupos de notificaci\u00f3n y horarios de escalada. Defines qui\u00e9n est\u00e1 de guardia, qu\u00e9 canales usa cada nivel y cu\u00e1nto tiempo espera una alerta antes de escalar a la siguiente persona. Se integra con los canales donde los equipos ya trabajan, as\u00ed una notificaci\u00f3n en Slack o Microsoft Teams llega a las personas activas y una escalada por PagerDuty cubre el camino fuera de horario. La idea es enrutar por gravedad, no enviar todo esperando que alguien lo note.<\/p>\n

Deja que los chequeos de dependencia supriman los s\u00edntomas<\/h2>\n

La tormenta de alertas es un problema estructural y lo resuelves estructuralmente. Tus chequeos tienen un orden de dependencia y la mayor\u00eda de los equipos lo ignora. Una petici\u00f3n a tu p\u00e1gina de checkout depende de que DNS resuelva, luego que TCP conecte, luego que termine el handshake TLS, luego que HTTP devuelva contenido, y finalmente que la transacci\u00f3n tenga \u00e9xito. Cuando algo abajo en esa pila falla, todo lo que est\u00e1 arriba tambi\u00e9n falla.<\/p>\n

As\u00ed que ordena tu monitoreo igual que el flujo de la petici\u00f3n y deja que la causa ra\u00edz silencie los s\u00edntomas. El monitoreo multiprotocolo de Dotcom-Monitor hace esto pr\u00e1ctico: observas DNS, TCP, TLS, HTTP y la transacci\u00f3n completa como chequeos separados, as\u00ed cuando algo falla puedes ver qu\u00e9 capa se rompi\u00f3 y alertar sobre esa en vez del efecto domin\u00f3 detr\u00e1s.<\/p>\n

\"Infograf\u00eda
Cuando una capa baja falla, todo lo que est\u00e1 arriba tambi\u00e9n falla. Alerta en la capa que fall\u00f3 primero.<\/figcaption><\/figure>\n

<\/p>\n