Saltar al contenido principal

Glosario de términos

Referencia rápida de los términos que aparecen en el panel, la documentación y las alertas.

A​

Assertion / Aserción Regla de validación que se evalúa sobre la respuesta de un check. Ejemplos: el código HTTP debe ser 200, el campo status del JSON debe ser "ok", la latencia debe ser inferior a 500 ms. Si una assertion falla, el paso o el check se marca como DOWN o DEGRADED según la configuración. Ver Assertions JSON para APIs.

C​

Canal de notificación Destino al que se envía una alerta: email, Slack, Discord, Google Chat, Telegram, Pushbullet, webhook, Zapier, Make, etc. Un canal se configura en Alertas → Canales y luego se asocia a uno o varios monitores mediante reglas de alerta. Ver Canales de notificación.

Check / Resultado de check Ejecución puntual de un monitor. Cada check produce un resultado (up, down o degraded) que se almacena en el historial. Los checks son realizados por los probes en las regiones configuradas.

Colas (task queues) Estructuras de mensajería donde el hub encola las verificaciones pendientes para que los probes las consuman. Las colas desacoplan la programación de los checks de su ejecución, permitiendo que varios probes trabajen en paralelo sin conflictos. Si la cola se satura por alta carga, los checks pueden retrasarse respecto al intervalo configurado — este es el origen del drift.

Consenso (validación multi-región) Mecanismo que requiere que una mayoría de probes regionales coincidan en un fallo antes de declarar un monitor como DOWN. Reduce falsos positivos causados por problemas de red local o interferencia puntual. Ver Validación multi-región.

Sin confirmar (medición parcial)​

Intervalo en el que aún no hubo consenso entre probes (barra gris en el dashboard). No equivale a Degradado ni a Caída. Ver Medición parcial — Sin confirmar.

D​

DEGRADED / Degradado Estado intermedio entre UP y DOWN. Un monitor está en DEGRADED cuando el servicio responde correctamente pero con calidad inferior a la esperada; la causa más común es latencia superior al umbral configurado en el monitor. DEGRADED no abre un incidente, pero puede disparar alertas si la regla correspondiente está activada. Ver Estados del monitor.

Disponibilidad Porcentaje de tiempo en que un monitor está UP en un periodo dado. Se calcula como el porcentaje de ejecuciones UP sobre el total de checks del periodo. Un check DEGRADED no cuenta como fallo para el cálculo de disponibilidad. Ver Uptime vs disponibilidad.

Drift (por carga del servidor) Desviación entre el momento programado de ejecución de un check o proceso y el momento en que realmente se ejecuta, causada por alta carga del servidor, saturación de colas o contención de recursos. En monitores Heartbeat, el drift puede hacer que un proceso envíe su ping dentro del período de gracia aunque esté funcionando correctamente. Configurar un período de gracia razonable (10–20 % del period) absorbe las variaciones normales de drift. Ver Grace.

DST (cambio de horario de verano) Daylight Saving Time: la transición estacional de horario (ej. de UTC+1 a UTC+2) puede afectar a cron jobs configurados con horas locales — un cron fijado a las «2:00 AM» puede ejecutarse dos veces o saltarse durante la transición según el sistema operativo. StatusInspector opera en UTC internamente; las fechas y horas visibles en el panel y la página de estado se muestran en la zona horaria configurada en tu cuenta.

E​

Error code Código corto que identifica el tipo de fallo del último check. Ejemplos: timeout, cert_expired, synthetic_assertion_failed, synthetic_variable_missing. Aparece en el historial del monitor, en los webhooks y en la traza sintética.

ETL (Extract, Transform, Load) Proceso automatizado que extrae datos de una o varias fuentes, los transforma (limpieza, enriquecimiento, agregación) y los carga en un destino (base de datos, data warehouse, etc.). Los pipelines ETL son un caso de uso habitual del monitor Heartbeat: el job envía un ping al finalizar para confirmar que el pipeline se ejecutó correctamente. Ver Monitorear cron jobs y tareas programadas.

Extractor En monitores synthetic multi-step: regla que extrae un valor de la respuesta de un paso (cuerpo JSON o cabecera HTTP) y lo guarda en una variable para usarlo en pasos siguientes. Ejemplo: extraer el token del paso de login para enviarlo como Authorization en el paso siguiente.

F​

Fail threshold / Umbral de fallos Número de checks consecutivos fallidos que deben acumularse antes de abrir un incidente y enviar alertas DOWN. Evita ruido por fallos momentáneos. Ver Umbrales y reglas.

Falso positivo Alerta de DOWN que no corresponde a una caída real del servicio. Causas comunes: problema de red en una sola región, flapping puntual, timeout transitorio. El consenso multi-región y el umbral de fallos reducen los falsos positivos. Ver Detectar falsos positivos.

G​

Grace / Período de gracia (Heartbeat) Tiempo de tolerancia adicional que el sistema espera más allá del period esperado antes de considerar que un heartbeat está en DOWN. Por ejemplo, con period = 1 hora y grace = 10 minutos, el monitor no pasa a DOWN hasta 1 hora 10 minutos después del último ping válido.

H​

Heartbeat Tipo de monitor donde es el sistema del cliente quien notifica periódicamente que un proceso sigue vivo, en lugar de que sea la plataforma quien comprueba activamente un endpoint. Útil para jobs batch, backups, ETLs y procesos internos sin URL pública. Ver Monitor Heartbeat.

Histéresis Mecanismo que requiere varios resultados consecutivos UP antes de marcar un monitor como recuperado tras haber estado DOWN. Evita que el monitor oscile entre DOWN y UP por fluctuaciones puntuales.

Hub Componente central de la arquitectura de StatusInspector. Publica el trabajo de verificación pendiente, consolida el consenso de los probes, gestiona incidentes, alertas y la API pública. No ejecuta checks directamente; delega la ejecución a los probes.

I​

Incidente Evento que representa una caída confirmada del servicio. Se abre automáticamente cuando el estado agregado pasa a DOWN y se cierra cuando el servicio se recupera a UP. Queda registrado con fecha y hora de inicio, resolución y duración total. DEGRADED no abre incidente. Ver Incidentes.

Interpolación de variables En monitores synthetic multi-step: sustitución de {{nombre_variable}} en URLs, cabeceras y cuerpos de petición por el valor extraído en pasos anteriores. Sintaxis con fallback: {{variable:valor_por_defecto}}.

J​

Jitter Variación irregular en la latencia de red o en el tiempo de ejecución de un proceso. Un check con jitter puede producir resultados alternos de UP/DOWN aunque el servicio esté operativo, porque la latencia fluctúa por encima y por debajo del timeout configurado. El umbral de fallos consecutivos y el consenso multi-región son las principales defensas contra el ruido generado por jitter. Ver Detectar falsos positivos.

L​

Latencia Tiempo en milisegundos que tarda el servicio en responder. En monitores HTTP y API, se compara con el umbral de latencia configurado en el monitor para determinar si el resultado es DEGRADED. En synthetic multi-step, también se registra por paso.

M​

Mantenimiento Modo que desactiva temporalmente las alertas e incidentes de un monitor durante ventanas planificadas de mantenimiento. Un monitor en mantenimiento sigue ejecutando checks pero no abre incidentes ni envía alertas de disponibilidad.

Monitor Configuración que define qué se comprueba, con qué frecuencia, con qué criterios y con qué alertas. Hay varios tipos: HTTP/Web, API (HTTP avanzado), TCP, DNS, SSL, Heartbeat, Ping ICMP y Synthetic multi-step.

MTBF (Mean Time Between Failures / Tiempo medio entre fallos) Tiempo promedio que transcurre entre dos incidentes consecutivos de un monitor. A mayor MTBF, mayor estabilidad del servicio. Disponible en el panel de monitores en planes Pro y Enterprise.

MTTR (Mean Time To Recovery / Tiempo medio de recuperación) Tiempo promedio que tarda un monitor en pasar de DOWN a UP, es decir, cuánto tarda el equipo en resolver un incidente. A menor MTTR, mayor capacidad de respuesta ante problemas. Disponible en el panel de monitores en planes Pro y Enterprise.

P​

Página de estado (Status page) Página web pública donde se muestra el estado actual de los servicios seleccionados, el historial de disponibilidad reciente y los incidentes activos o resueltos. Se comparte con clientes como canal oficial de comunicación de estado. Ver Crear página de estado.

Period (Heartbeat) Intervalo esperado entre pings válidos en un monitor Heartbeat. Por ejemplo, period = 1 hora indica que el proceso debe enviar un ping cada hora.

Ping / ICMP Tipo de monitor que comprueba la conectividad de red hacia un host mediante ICMP echo. Es ejecutado exclusivamente por los probes. Ver Monitor Ping (ICMP).

Pipelines Flujos de procesamiento automatizados compuestos por una secuencia de pasos. En el contexto de monitoreo: (1) pipelines de datos o ETL cuya ejecución se verifica con monitores Heartbeat; (2) pipelines de CI/CD que crean o actualizan monitores mediante la API pública. Ver Monitorear cron jobs y tareas programadas y Monitores vía API.

Plantilla de escenario Escenario synthetic multi-step guardado en la cuenta para reutilizarlo al crear o editar monitores. Permite que equipos con patrones de monitoreo similares compartan configuraciones sin reescribirlas. Disponible en planes Pro y Enterprise.

Probe / Nodo regional Agente ligero desplegado en una región geográfica que consulta periódicamente las verificaciones pendientes, las ejecuta localmente y reporta los resultados al hub. Varios probes ejecutan el mismo monitor para que el consenso filtre falsos positivos.

Q​

Quórum Ver Consenso.

R​

Rate limiting Límite de peticiones por minuto a la API pública. Se comunica en los headers de respuesta X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset. El endpoint de Heartbeat también aplica límites por token para evitar abuso.

Retención de datos Política que determina durante cuánto tiempo se almacena el historial de checks, incidentes y alertas. Ver Retención de datos.

Rol Nivel de acceso asignado a cada miembro del equipo en una cuenta. Los roles disponibles son: Owner (control total de la cuenta), Admin (gestión completa de monitores, canales y miembros), Editor (crear y editar monitores y reglas de alerta) y Viewer (solo lectura). Ver Equipo y roles.

S​

Scheduler Componente del hub que determina cuándo es hora de ejecutar cada monitor según su intervalo configurado y publica las verificaciones pendientes para los probes.

Scope (API) Permiso granular de un token de API. Ejemplos: monitors:read, checks:read, status_pages:write. Un token solo puede realizar las acciones correspondientes a sus scopes asignados. Ver Autenticación de la API.

Servidores bare metal Servidores físicos dedicados, sin capa de virtualización ni contenedor compartido, donde se ejecutan los probes de StatusInspector. Al no compartir CPU ni red con otros inquilinos, los bare metal reducen el jitter y el drift en los tiempos de ejecución de los checks, lo que mejora la precisión de las mediciones de latencia.

SLA (Service Level Agreement) Acuerdo formal de nivel de servicio entre proveedor y cliente que define el mínimo de disponibilidad comprometida, habitualmente expresado como porcentaje mensual (ej. 99,9 %).

SLO (Service Level Objective) Objetivo interno de nivel de servicio. Suele ser más estricto que el SLA y sirve de alerta temprana antes de incumplirlo. Ver Uptime vs disponibilidad.

Monitores sintéticos / Synthetic / Monitor synthetic multi-step Modo avanzado del monitor HTTP que ejecuta varios pasos encadenados (login, extracción de token, llamada autenticada, verificación de respuesta, etc.) simulando un flujo de usuario real. Cada paso puede tener sus propias assertions y extractores. Ver Synthetic multi-step.

T​

Token (API) Credencial Bearer para autenticarse en la API pública de StatusInspector. Se genera desde el panel y tiene scopes asignados y, opcionalmente, una fecha de expiración. Ver Autenticación de la API.

Token (Heartbeat) Secreto único por monitor Heartbeat que forma parte de la URL de ping. Garantiza que solo el proceso autorizado puede reportar la señal de vida. Puede rotarse desde el panel sin perder el historial.

U​

Uptime Ver Disponibilidad.

W​

Workers Procesos en segundo plano que consumen tareas de una cola y las ejecutan de forma asíncrona. En StatusInspector, los workers del hub gestionan el envío de alertas, la agregación de métricas y el procesamiento de resultados de checks. Si los workers se saturan por alta carga, los checks pueden procesarse con retraso aunque el probe los haya ejecutado a tiempo — este es un origen de drift en el sistema. En el contexto del cliente, un «worker» (proceso batch interno) es uno de los casos de uso más habituales del monitor Heartbeat. Ver Monitorear cron jobs y tareas programadas.