Cómo funciona el monitoreo

StatusInspector monitoriza tus servicios desde múltiples puntos geográficos al mismo tiempo, consolida los resultados y solo te alerta cuando hay evidencia real de un problema. Esta página explica cómo funciona ese proceso.

Los dos componentes: Hub y Probes

El sistema tiene dos piezas con roles bien separados:

Hub (control central) : El cerebro del sistema. Orquesta todos los monitores, decide cuándo y desde dónde ejecutar cada check, recibe los resultados de las distintas regiones, aplica la lógica de consenso, gestiona incidentes y envía alertas. No ejecuta checks directamente.

Probes (agentes regionales) : Agentes ligeros desplegados en distintas regiones geográficas. Cada probe consulta periódicamente el hub para recoger las verificaciones pendientes asignadas a su región, las ejecuta de forma local e independiente, y reporta el resultado de vuelta. Los probes operan de forma autónoma: no dependen de conexiones persistentes ni de que el hub los contacte directamente. Las decisiones sobre incidentes y alertas son exclusivas del hub.

  Hub (central)
  ├── Publica verificaciones pendientes
  ├── Consolida resultados regionales
  ├── Abre / cierra incidentes
  └── Envía alertas

  ── Fase 1: cada probe consulta trabajo pendiente ──────────────
  Probe América  →  Hub: "¿Hay checks para mi región?"
  Probe Europa   →  Hub: "¿Hay checks para mi región?"
  Probe Asia     →  Hub: "¿Hay checks para mi región?"
                    Hub → Probe: parámetros del monitor

  ── Fase 2: cada probe ejecuta localmente y reporta ────────────
  Probe América  →  ejecuta check  →  reporta resultado al Hub
  Probe Europa   →  ejecuta check  →  reporta resultado al Hub
  Probe Asia     →  ejecuta check  →  reporta resultado al Hub

  ── Fase 3: el Hub decide ──────────────────────────────────────
                    Hub: consenso → estado → incidente → alerta

El ciclo de un check

Cada vez que un monitor está listo para ejecutarse, el proceso sigue estos pasos:

Programación — el scheduler del hub detecta que es momento de ejecutar el monitor según su intervalo configurado (por ejemplo, cada minuto).
Publicación — el hub registra el check como trabajo pendiente, disponible para los probes de las regiones activas. El número de probes que pueden tomarlo depende de tu plan (1, 3 o 5 nodos).
Consulta y ejecución — cada probe interroga al hub en busca de trabajo pendiente para su región, toma la verificación asignada y la ejecuta localmente de forma independiente: hace la petición HTTP, abre la conexión TCP, consulta el DNS, envía el ping ICMP, etc.
Reporte — el probe envía el resultado al hub: estado (up, down o degraded), latencia medida en milisegundos, y detalles del error si los hay.
Consenso — el hub acumula los resultados de todos los probes en una ventana de tiempo y calcula el estado global del monitor.
Incidente — si el estado cambia (por ejemplo, de up a down), el hub abre un incidente automáticamente.
Alerta — el hub envía notificaciones a los canales configurados según las reglas del monitor.

Consenso multi-región: sin falsas alarmas

La clave para evitar alertas innecesarias es el consenso multi-región: el hub no declara una caída basándose en el resultado de un solo probe, sino en la coincidencia de varios probes independientes.

Ejemplo con 3 probes (plan Pro):

Probe América	Probe Europa	Probe Asia	Resultado
DOWN	DOWN	UP	DOWN confirmado (2 de 3 coinciden)
DOWN	UP	UP	Descartado — falla local o transitoria
DOWN	DOWN	DOWN	DOWN confirmado (unanimidad)

Esto filtra problemas puntuales de red, picos de latencia momentáneos y errores transitorios del probe — que de otro modo generarían alertas falsas.

El número de probes que participan por check depende de tu plan:

Plan	Probes por check
Free	1
Pro	3
Enterprise	5

Estados de salud

Cada ciclo de check produce uno de estos tres estados:

Estado	Significado
UP	El servicio responde correctamente en la mayoría de regiones.
DEGRADED	Responde, pero con latencia alta u otras señales de deterioro.
DOWN	El servicio falla en la mayoría de regiones activas.

El estado DEGRADED es intermedio: el sistema espera confirmar varias evaluaciones consecutivas antes de considerarlo definitivo, para evitar ruido por resultados contradictorios puntuales entre regiones. Recibirás una alerta de degradación, y cuando el servicio se recupere, una alerta de recuperación.

Del fallo al incidente y la alerta

Este es el flujo completo desde que un servicio cae hasta que se resuelve:

Servicio cae
  → Probes detectan DOWN
  → Consenso confirma DOWN
  → Incidente abierto (fecha y hora de inicio registrada)
  → Alerta enviada: "Tu servicio está DOWN"

[Servicio en DOWN durante N minutos...]

  → Probes detectan que el servicio responde de nuevo
  → Consenso confirma recuperación
  → Incidente cerrado (duración total calculada)
  → Alerta de recuperación enviada

¿Cuánto tarda en detectar una caída? Depende del intervalo del monitor. Con un intervalo de 1 minuto (plan Pro), el tiempo máximo de detección es de aproximadamente 60 segundos desde que ocurre el fallo.

Monitores Heartbeat: el modo inverso

Para procesos internos sin URL pública — backups nocturnos, crons, pipelines de datos — el modelo se invierte: tu sistema llama a StatusInspector, en lugar de que StatusInspector llame a tu sistema.

Así funciona:

StatusInspector te asigna una URL única para el monitor.
Cuando tu proceso termina correctamente, envía una señal GET o POST a esa URL.
StatusInspector espera esa señal dentro de una ventana configurable:
- period — cada cuánto tiempo esperas que llegue la señal (ej. cada 24 horas).
- grace — margen de tolerancia adicional antes de declarar fallo (ej. 30 minutos).
Si la señal no llega dentro del periodo más la gracia, se abre un incidente y se envía una alerta.

Ejemplo práctico:

Tienes un backup que corre cada noche a las 2:00 a.m. y normalmente tarda unos 20 minutos. Configuras el heartbeat con period = 24 horas y grace = 30 minutos. Si a las 2:50 a.m. no se ha recibido la señal, StatusInspector te avisa inmediatamente.

Los monitores Heartbeat están disponibles en los planes Pro y Enterprise.

Mantenimiento programado

Si tienes actualizaciones o cambios de infraestructura planificados, puedes activar una ventana de mantenimiento en el monitor. Durante ese periodo:

StatusInspector sigue ejecutando checks con normalidad.
Las alertas se suprimen para evitar ruido innecesario.
Los resultados quedan registrados en el historial para auditoría.

Cuando la ventana finaliza, el sistema retoma el envío de alertas automáticamente.

Los dos componentes: Hub y Probes​

El ciclo de un check​

Consenso multi-región: sin falsas alarmas​

Estados de salud​

Del fallo al incidente y la alerta​

Monitores Heartbeat: el modo inverso​

Mantenimiento programado​