Cómo reducir falsos positivos en el monitoreo de uptime
Un falso positivo en monitoreo sintético es, en la práctica: el sistema dice DOWN o dispara alerta cuando el servicio sigue siendo correcto para la mayoría de los usuarios. No es un “detalle de métrica”: corroe la confianza del equipo, entrena a la gente a ignorar el canal (alert fatigue) y retrasa la reacción cuando ocurre un verdadero SEV-1.
StatusInspector combina varias capas para evitarlo: timeouts razonables, consenso multi-región (cuando el plan lo permite), agregación de incidentes y reglas de alerta que distinguen DOWN, DEGRADED y recuperación.
Dónde nace el ruido (y qué hacer)
1) Red y transporte
Microcortes, pérdida puntual de paquetes, DNS lento o un TLS handshake inusual pueden hacer fallar un check aislado sin que el servicio haya caído.
Qué hacer: sube un poco el timeout del monitor si estaba al límite; evita dejarlo en el mínimo “teórico” si la API hace cola a veces. Revisa con tu proveedor de nube o CDN si el patrón coincide con despliegues o purgas de caché.
2) Un solo punto de observación
Si todo el monitoreo sale de la misma región o del mismo host, un problema de ruta o peering local puede dar DOWN aunque el resto del mundo vea el servicio.
Qué hacer: activa o profundiza la validación multi-región (ver más abajo): el hub sigue siendo la autoridad que abre y cierra incidentes, pero un probe en otra red puede confirmar o matizar el fallo.
3) Intervalos muy agresivos
Con intervalos cortos y destinos sensibles al jitter, cualquier microcorte puede producir más transiciones de estado y más notificaciones.
Qué hacer: valora un intervalo algo mayor si el SLO lo permite; ajusta timeout y revisa el consenso entre regiones en la documentación del producto. Más detalle: Estados del monitor y Validación multi-región.
4) Re-alertas y duplicados
Un diseño sano no debería spamear el mismo incidente en cada check mientras dura el fallo; la utilidad está en el inicio y en la recuperación.
Qué hacer: apóyate en el flujo de incidentes y canales: DOWN al abrir, aviso al resolver, y canales degradados si el producto los soporta para señales no críticas.
Validación multi-región: la idea en una frase
El hub (control plane) programa los checks y decide estado e incidentes. Los probes regionales consultan al hub qué verificaciones tienen pendientes, ejecutan el check de forma independiente y reportan el resultado. El hub agrega los resultados antes de decidir si el fallo es suficientemente consistente entre regiones para abrir un incidente.
Esto no sustituye un APM; reduce el clásico “a mí me carga” frente a “nuestro monitor dice caído”.
- Los probes en distintas redes o regiones consultan al hub las verificaciones pendientes.
- Cada probe ejecuta el check de forma independiente desde su propia red.
- El hub agrega los resultados y aplica el consenso multi-región antes de decidir si abrir un incidente o notificar.
El máximo de probes por check depende del plan: 1 en Free, 3 en Pro, 5 en Enterprise. Detalle de operación: Validación multi-región.
Checklist rápido (accionable)
- Revisa timeout y intervalo mínimo permitido por plan.
- Revisa intervalo, timeout y probes del plan si el canal es demasiado nervioso.
- Asegúrate de que workers y colas del hub estén sanos; colas atascadas se confunden con “el mundo está caído” cuando en realidad no se procesan jobs.
- Si está disponible para tu cuenta, configura y entiende la confirmación multi-región antes de prometer SLAs a clientes.
- Documenta en el equipo qué significa DEGRADED frente a DOWN: Estados del monitor.