Para reducir las falsas alertas en la monitorización de uptime, confirma cada fallo con una segunda comprobación antes de alertar, fija timeouts acordes con el comportamiento normal de tu web, comprueba que una URL que refleje de verdad el servicio devuelve el código de estado y el contenido esperados, envía las alertas de cada monitor solo a quien puede actuar, mete el trabajo planificado en una ventana de mantenimiento y anúncialo, y revisa cada mes los monitores que más ruido hacen. La mayoría de las falsas alertas vienen de unos pocos monitores con uno de estos ajustes mal configurado, así que corregirlos suele ser rápido.
Esta guía explica por qué las falsas alertas son peligrosas, de dónde vienen y qué cambiar, ajuste por ajuste.
Por qué las falsas alertas son peores de lo que parecen
Una falsa alerta es una pequeña molestia. Un goteo constante es fatiga de alertas: la gente silencia el canal, manda los emails a una carpeta o mira el móvil y vuelve a dormirse. La monitorización sigue funcionando, pero nadie escucha. La primera caída real a partir de ese momento se descubre a la antigua: por un cliente.
También hay un coste más silencioso. Cada falsa alerta saca a alguien de su trabajo para revisar una web que funciona bien. En un mes, eso suma horas de concentración perdida y un equipo que confía menos en sus herramientas. El objetivo no es tener menos alertas porque sí, sino alertas que merezca la pena leer siempre.
De dónde vienen las falsas alertas
Cortes momentáneos de red entre una ubicación de comprobación y tu servidor: un paquete perdido, una ruta lenta, un fallo breve de DNS.
Timeouts demasiado ajustados para una página que a veces va lenta pero funciona.
Una expectativa equivocada: una comprobación que espera un estado 200 de una URL que redirige, o que busca un texto que cambió con un rediseño.
La URL equivocada: una página con limitación de peticiones, protección contra bots o inicio de sesión, o un servidor de staging que se apaga por la noche.
Trabajo planificado: despliegues y mantenimientos que tiran una web a propósito.
Un enrutamiento incorrecto: una alerta técnicamente correcta, pero enviada a alguien que no puede hacer nada. Para esa persona, es ruido.
Confirma cada fallo con una segunda comprobación
Es la solución más eficaz. Cuando una comprobación falla, vuelve a comprobar antes de hacer nada más. Un paquete perdido o un fallo breve supera la segunda comprobación; una caída real vuelve a fallar. Solo un fallo confirmado abre una incidencia. Así se eliminan la mayoría de los cortes momentáneos sin retrasar las alertas reales más de unos segundos.
Los servicios que comprueban desde varias ubicaciones pueden hacer la segunda comprobación desde otro lugar, lo que además te da información útil cuando las ubicaciones discrepan durante más tiempo. Si tu web falla desde un continente y funciona desde otro, lo más probable es que el problema sea de enrutamiento o de un nodo de la CDN, no de tu servidor. Uptimecheck comprueba desde Estocolmo, Londres y Nueva York, y confirma cada fallo desde una segunda ubicación antes de abrir una incidencia, para que un corte puntual no despierte a nadie; la página de monitorización de uptime explica el proceso. Para entender lo básico de cómo las comprobaciones se convierten en alertas, consulta qué es la monitorización de uptime.
Fija timeouts acordes con la realidad
El timeout es el tiempo que una comprobación espera antes de dar la web por caída. Si es demasiado ajustado, la variación normal se convierte en una caída. Si es demasiado holgado, una web que tarda 40 segundos en responder cuenta como disponible.
Revisa el historial de tiempos de respuesta de unas cuantas semanas. Anota el rango normal y las respuestas normales más lentas.
Fija el timeout con margen por encima de la respuesta normal más lenta, pero por debajo del punto en que los visitantes se rinden.
Trata la lentitud como una señal aparte. Una página que ha pasado de 300 ms a 4 segundos necesita atención, pero en horario laboral, no como una alerta de caída por la noche.
Si una página se queda a menudo cerca del timeout, el problema no es el monitor, sino la página.
Espera el código de estado y el contenido correctos
Muchas falsas alertas vienen de comprobaciones que esperan lo que no es:
Redirecciones. Monitorizar http://northwind.shop cuando la web redirige a https://www.northwind.shop/ añade un salto que puede fallar por sí solo. Monitoriza directamente la URL final y, si quieres verificar la redirección, dale su propio monitor.
Comprobaciones de contenido frágiles. Validar un titular de marketing falla con el siguiente cambio de texto. Elige algo estable que solo aparezca cuando la página funciona, como el nombre de la empresa en el pie, un elemento de la cuadrícula de productos o «status»:»ok» de un endpoint de salud.
Demasiado amplias. Aceptar cualquier código 2xx o 3xx oculta fallos reales. Aceptar solo 200 de un endpoint que devuelve 204 de forma legítima genera falsos. Ajústalo a lo que devuelve realmente el endpoint.
Validar el contenido reduce a la vez las falsas alertas y las alertas perdidas: una página de error de un proxy que devuelve 200 no pasa la comprobación, y un cambio estético sí.
Monitoriza la URL correcta
Algunas URL son por naturaleza malos objetivos de monitorización. Las páginas con protección contra bots o detrás de un firewall de aplicaciones web pueden bloquear de vez en cuando el tráfico de monitorización, lo que parece una caída. Las páginas con una limitación de peticiones estricta pueden devolver 429 tras una ráfaga de comprobaciones. Las páginas protegidas con inicio de sesión devuelven una redirección al formulario de acceso. Y la página de inicio suele estar tan cacheada que sigue disponible aunque todo lo que hay detrás esté caído.
Un endpoint de salud dedicado evita todo esto. No se cachea, cuesta poco servirlo, devuelve un cuerpo predecible y solo falla cuando falla una dependencia. Consulta cómo crear un endpoint de health check. Si necesitas monitorizar una página protegida, deja pasar al servicio de monitorización y envía una cabecera de user agent reconocible para que el tráfico sea fácil de identificar.
Envía las alertas por monitor
Una alerta solo es útil para quien puede actuar. Enviar todos los monitores a todo el mundo convierte las alertas reales en ruido para la mayoría de quienes las reciben. En su lugar, enruta según el impacto y la responsabilidad:
Monitor (ejemplo)CanalQuiénCheckout y callback de pagoNotificación push y chat del equipoQuien esté de guardiaEndpoint de salud de la API públicaChat del equipo y webhookEquipo de plataformaWeb de marketing y blogEmailEquipo web, en horario laboralStaging y herramientas internasCanal de chat aparteQuien sea responsable
En Uptimecheck eliges los canales de alerta de cada monitor. Las alertas llegan por email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks y notificaciones push en el móvil, en todos los planes. Consulta alertas y notificaciones. Con los turnos de guardia, las alertas push llegan a quien esté de guardia en ese momento, y el escalado puede retener un canal entre 5 y 60 minutos y avisar solo si nadie ha reconocido la incidencia. Las agencias pueden agrupar los monitores por proyecto de cliente y elegir los canales de cada monitor, para que las alertas de cada cliente lleguen al equipo que lo atiende.
Gestiona el mantenimiento planificado
Una caída planificada nunca debería despertar a nadie. Antes de una migración o un despliegue largo, mete los monitores afectados en una ventana de mantenimiento. Si tu herramienta no las tiene, páusalos o lleva sus alertas a un canal tranquilo mientras dure, y añade la reactivación de la monitorización como un punto de tu checklist de despliegue.
En Uptimecheck, las ventanas de mantenimiento pueden ser puntuales o recurrentes. Durante una ventana no hay alertas, ni incidencias, ni pérdida de uptime, y la ventana se muestra en tu página de estado y puede enviarse por email a los suscriptores.
Avisa también a tus clientes. Una nota en tu página de estado antes del trabajo, con la franja horaria y lo que se verá afectado, hace que nadie se lleve una sorpresa y que soporte no reciba tickets sobre algo que tenías planificado. Los despliegues que provocan unos segundos de errores cada vez son otro problema: resuélvelos con despliegues progresivos o sin tiempo de inactividad, no ignorando las alertas.
Usa avisos de recuperación
Un aviso de recuperación es la alerta que dice que ya ha pasado, con el tiempo total de caída. No reduce el número de alertas, pero sí el trabajo que genera cada una. Sin él, alguien tiene que seguir comprobando si una caída corta ha terminado. Con él, un corte de dos minutos por la noche es una alerta y un aviso de que todo está bien que puede esperar a la mañana. Uptimecheck envía un aviso de recuperación después de cada incidencia.
Revisa los monitores que más ruido hacen
Una vez al mes, haz una lista de los monitores que más alertaron y pregúntate sobre cada uno:
¿Era real cada alerta? Si no, ¿qué ajuste la provocó: ubicación, timeout, expectativa o URL?
¿Actuó alguien? Si nunca actúa nadie, cambia el enrutamiento o elimina el monitor.
¿Es la propia web inestable? Las caídas reales cortas y frecuentes no son falsas alertas; apuntan a un servidor sobrecargado o a una dependencia débil, y los umbrales de alerta del servidor pueden ayudarte a encontrar la causa.
¿Sigue haciendo falta el monitor? Las webs retiradas y los servidores de staging antiguos son una fuente habitual de ruido.
Los informes semanales y mensuales por email que resumen el uptime y las incidencias hacen que esta revisión sea rápida.
Checklist contra las falsas alertas
Confirma cada fallo con una segunda comprobación antes de alertar.
Fija los timeouts a partir del historial real de tiempos de respuesta.
Monitoriza las URL finales, no las redirecciones, y valida contenido estable.
Prioriza los endpoints de salud frente a páginas cacheadas o protegidas.
Envía cada monitor a las personas que pueden actuar.
Mete el trabajo planificado en una ventana de mantenimiento y anúncialo.
Revisa cada mes los monitores que más ruido hacen.
Resumen
Las falsas alertas son un problema de configuración, y la mayoría se pueden corregir en una tarde. Confirma cada fallo con una segunda comprobación, comprueba lo correcto en la URL correcta, envía las alertas solo a donde se puede actuar y sigue revisando. La recompensa es un equipo que lee todas las alertas, porque todas importan.
Uptimecheck vuelve a comprobar cada fallo antes de alertar y te permite enviar las alertas por monitor. Empieza una prueba gratuita de 14 días, sin tarjeta de crédito.