Supervisión

La sección Supervisión de Joryio permite configurar alertas que se activan cuando algo importante supera un umbral: el tráfico entrante de la API, los webhooks que Joryio entrega desde tus recorridos, los eventos de cliente que registra tu aplicación o SDK, o tus tasas de entregabilidad (rebotes, quejas y entregas). Cada alerta vigila una sola métrica, se evalúa cada minuto y te avisa por email o webhook cuando pasa de correcta a activada.

Abre Configuración → Registros y supervisión en el panel para gestionar alertas y revisar activaciones anteriores.

El centro de Registros y supervisión

Supervisión está dentro del centro unificado de Registros y supervisión, accesible desde una única entrada de la barra lateral. La barra izquierda agrupa cuatro áreas:

Área	Qué muestra
Alertas	Todas las reglas de alerta del espacio de trabajo, su estado actual y acciones rápidas (posponer, pausar, editar, eliminar o duplicar).
Historial	Registro de solo anexado de cada vez que una alerta entra o sale del estado activado. Sirve para el análisis posterior a un incidente.
Registros de errores	Errores de entrega y procesamiento de todos los canales, para depurar envíos fallidos.
Auditoría	Acciones de administración, errores de entrega y eventos de autenticación. Consulta Registro de auditoría.

Esta página explica Alertas e Historial, es decir, la función de alertas. Las activaciones y resoluciones también llegan a la campana de la cabecera del panel, con un estado de lectura propio de cada persona (consulta Notificaciones), para que no tengas que dejar el centro abierto para detectar un incidente.

Crear una alerta

Haz clic en + Nueva alerta en la página Alertas. El formulario Nueva alerta es un asistente de tres pasos con una barra izquierda fija que muestra tu progreso:

Paso	Título	Qué configuras
1	Métrica: qué vigilar	Elige una plantilla de inicio rápido (o crea la tuya), nombra la alerta y selecciona la dirección y la métrica.
2	Condición: cuándo se activa	Elige entre valor absoluto o comparación de cambios, define el umbral, delimita la alerta opcionalmente y consulta una vista previa en tiempo real.
3	Notificar: a quién avisar	Revisa el resumen, elige el canal de notificación (email o webhook) y define el periodo de espera y el estado activo.

Puedes volver a cualquier paso terminado desde la barra. Siguiente está bloqueado hasta que la alerta tenga un nombre; desde el paso 2, el pie muestra una etiqueta de estado en tiempo real (Se activaría ahora / Correcta / En pausa).

Paso 1: Métrica

Empezar con una plantilla

Las plantillas prediseñadas cubren los casos más habituales en tres grupos. Al elegir una se completan todos los pasos, pero puedes ajustar cualquier detalle antes de guardar. Haz clic en Limpiar para volver a una configuración vacía.

Entrante: llamadas a la API de Joryio

Plantilla	Se activa cuando
Fallo silencioso de integración	El total de llamadas cae ≥80 % frente a la hora anterior. Detecta un despliegue que rompió la integración.
Error de autenticación	Más de 100 respuestas 401 Unauthorized en 5 minutos. Detecta un despliegue que invalidó una clave de API.
El servidor rechaza cargas	Más de 100 respuestas 5xx en 5 minutos. Normalmente significa que cambió el formato de la solicitud y Joryio ya no puede interpretarlo.
Pico de tráfico	El total de llamadas aumenta un 200 % frente a la hora anterior. Detecta un script descontrolado o un aumento inesperado.

Saliente: webhooks que Joryio envía desde tus recorridos

Plantilla	Se activa cuando
Fallo del endpoint de webhook	Más de 50 respuestas 5xx en entregas de webhook en 5 minutos. El endpoint no está disponible o la ruta ya no existe.
El webhook dejó de activarse	Las entregas de webhook caen ≥90 % frente a la hora anterior. El recorrido está en pausa, la audiencia se agotó o la cola se bloqueó.

Eventos: caídas de embudo en tus eventos registrados

Plantilla	Se activa cuando
Caída del embudo de compra	Los eventos purchase_complete caen ≥50 % frente al mismo día de la semana pasada.
Caída de añadir al carrito	Los eventos add_to_cart caen ≥30 % frente a la misma hora de la semana pasada.
Caída de registros	Los eventos signup caen ≥50 % frente al mismo día de la semana pasada.
Caída de usuarios activos	Los usuarios únicos que activan eventos caen ≥40 % frente al mismo día de la semana pasada.

¿Por qué «la semana pasada»?

Las plantillas de Eventos comparan con la misma ventana de la semana pasada, no con la ventana inmediatamente anterior. Los eventos de cliente tienen una marcada estacionalidad semanal y horaria; una bajada el domingo por la noche es normal, no un incidente. Comparar con la hora anterior produciría falsas alertas constantemente. Consulta Comparar con más abajo.

Entregabilidad: tasas de salud de los mensajes en todos los canales

Plantilla	Se activa cuando
Tasa de rebote alta	La tasa de rebote supera el 5 % en las últimas 24 h. Puede indicar un problema de calidad de lista o reputación del remitente.
Tasa de quejas alta	La tasa de quejas supera el 0,1 % en las últimas 24 h. Mantente por debajo de los umbrales de spam de los proveedores de correo.
Tasa de entrega baja	La tasa de entrega baja del 95 % en las últimas 24 h. Menos mensajes están llegando a las bandejas de entrada.

Datos básicos

Campo	Qué hace
Nombre de la alerta	Obligatorio. Aparece en el panel, en el asunto del email activado o la carga del webhook y en el Historial. No puedes pasar al paso 2 hasta completarlo.
Descripción	Opcional. La ven los compañeros que consultan alertas y aparece en el cuerpo del email para que el equipo de guardia sepa de qué trata la alerta.

Dirección

Elige qué flujo vigila la alerta:

• API entrante: cuenta solicitudes que llegan a la API REST de Joryio (por ejemplo, tus servidores llamando a POST /events).
• Webhooks salientes: cuenta entregas de webhook que salen de Joryio, enviadas desde un nodo de webhook de un recorrido de usuario.
• Eventos: cuenta los eventos de cliente registrados desde tu SDK o aplicación al llegar a Joryio. Vigila el número de eventos almacenados, no el número de llamadas entrantes a la API. Ambos difieren cuando Joryio acepta una llamada pero rechaza su carga; ese caso pertenece a API entrante.
• Entregabilidad: vigila las tasas de salud de los mensajes (rebote, queja, entrega, etc.) medidas como porcentaje de mensajes enviados en una ventana retrospectiva. Cubre todos los canales que pueden informar de la métrica, agrupados como media ponderada por envíos: tasa de entrega en los cinco canales, tasa de bajas en email y SMS, y rebote y quejas en email, el único canal que los tiene. Antes evaluaba solo el email, así que un espacio de trabajo que envía sobre todo SMS o push vigilaba una tasa a la que su tráfico apenas contribuía. A diferencia de las direcciones basadas en recuento, la entregabilidad siempre usa el modo absoluto (un umbral sobre la tasa) y no tiene filtro de alcance: cubre todos los mensajes enviados desde el espacio de trabajo.

Las etiquetas de métrica que aparecen a continuación se adaptan a la dirección elegida.

Métrica

Entrante / Saliente

Métrica	Qué mide	Cuándo usarla
Llamadas / Entregas por código de respuesta	Recuento de llamadas filtrado por los códigos de estado HTTP que elijas.	Alertas de tasa de error (401, 429, 5xx).
Total de llamadas / entregas	Recuento de todas las llamadas, independientemente del estado.	Alertas como «¿mi integración dejó de funcionar?» o «¿el tráfico se disparó?».
Solicitudes / Entregas por segundo	Rendimiento medio durante la ventana de evaluación.	Alertas de capacidad por clave o endpoint.

Eventos

Métrica	Qué mide	Cuándo usarla
Recuento de eventos	Recuento de un único evento (por ejemplo, purchase_complete).	La alerta clásica de caída de embudo; combínala con modo Cambio y la misma ventana de la semana pasada.
Total de eventos	Recuento de todos los eventos registrados, sin importar su nombre.	Detecta que tu SDK quedó completamente inactivo (un despliegue rompió la inicialización o la aplicación falló para una cohorte).
Usuarios únicos	Usuarios distintos que activan el evento seleccionado, o cualquier evento si no eliges uno.	Problemas de audiencia frente a picos de usuarios avanzados; mejor que el recuento bruto.

Entregabilidad (siempre en modo absoluto; el umbral es un porcentaje. Elige una ventana retrospectiva de 1 h / 4 h / 24 h / 7 d):

Métrica	Qué mide	Cuándo usarla
Tasa de rebote	Rebotados ÷ enviados.	El principal indicador de llegada a bandeja de entrada; alerta por encima de ~2–5 %.
Tasa de quejas	Quejas de spam ÷ enviados.	Los proveedores de buzón limitan por encima de ~0,1–0,3 %; alerta pronto.
Tasa de rebote duro / suave	Rebotes permanentes o transitorios ÷ enviados.	Separa los rebotes duros, que dañan la reputación, de los suaves transitorios.
Tasa de bajas	Bajas ÷ enviados.	Fatiga por contenido o frecuencia.
Tasa de entrega	Entregados ÷ enviados.	Usa el operador Por debajo de para activar la alerta cuando la entrega caiga por debajo de un nivel sano (por ejemplo, < 95%).

Cada tasa de arriba se agrupa sobre los canales que la emiten, ponderada por cuánto envió cada uno, para que un canal de poco volumen no pueda mover la alerta por sí solo.

nota

Las alertas de entregabilidad necesitan volumen para ser relevantes: si no se enviaron mensajes durante la ventana retrospectiva, la alerta nunca se activa. Así, una alerta delivery rate < 95% no producirá una falsa alarma en una noche tranquila.

Códigos de respuesta (entrante/saliente, cuando corresponda)

Cuando la métrica es por código de respuesta, elige qué estados HTTP cuentan. El selector agrupa los códigos en:

• Grupos: 2xx, 4xx, 5xx o todos los códigos.
• Correctos: 200, 201, 202, 204.
• Errores de cliente: 400, 401, 403, 404, 422, 429.
• Errores de servidor: 500, 502, 503, 504.

Puedes combinar grupos y códigos concretos (por ejemplo, «5xx o 429»).

Paso 2: Condición

Comparar con

Dos modos de evaluación:

Modo	Comportamiento
Absoluto	Se activa cuando la métrica cruza un valor fijo durante una ventana sostenida. «Más de 100 errores en 5 minutos».
Cambio a lo largo del tiempo	Se activa cuando la métrica aumenta o disminuye un % (o una cantidad absoluta) frente a una ventana anterior. «Las llamadas cayeron un 80 % frente a la hora anterior».

Campos del modo absoluto:

• Por encima de / Por debajo de: dirección del umbral.
• Valor del umbral: valor numérico que debe cruzar la métrica.
• Durante X tiempo: la métrica debe mantenerse al otro lado del umbral durante toda esta ventana antes de que se active la alerta. Opciones: 1 m, 5 m, 10 m, 30 m, 1 h.

Campos del modo Cambio:

• Aumentó / Disminuyó en: dirección del cambio.
• Valor del umbral: el % o la cantidad absoluta de cambio.
• % o abs: interpreta el umbral como porcentaje o recuento absoluto.
• frente a la ventana X anterior: tamaño de la ventana de comparación. Opciones: 15 m, 1 h, 4 h, 1 d, 7 d.
• Comparar con: con qué comparar la ventana actual (ver abajo). Solo aparece en modo Cambio.

Comparar con (comparación estacional)

En modo Cambio, la alerta puede comparar la ventana actual con una de estas dos referencias:

Opción	Compara la ventana actual con…	Ideal para
Un día típico como este (recomendado)	La mediana de la misma ventana 7, 14, 21 y 28 días atrás.	Casi todo, y en especial las alertas de caída porcentual. Absorbe la estacionalidad semanal y, al ser una mediana, un día grande no la mueve.
Inmediatamente anterior	La ventana inmediatamente anterior (el valor predeterminado, el comportamiento clásico).	Tráfico de API/webhook sin un patrón marcado por hora del día.
Misma ventana la semana pasada	El mismo tramo exactamente hace 7 días.	Eventos de embudo con estacionalidad semanal o diaria (la mayoría de las aplicaciones de consumo), donde la hora anterior daría falsas alertas.

Por qué importa la mediana. Las otras tres se rompen igual: dejan que un día atípico fije la línea base. Compara con ayer y cada lunes parece una caída después de un domingo tranquilo. Compara con el mismo día de la semana pasada y una campaña o un artículo ese día hacen que hoy parezca roto. Incluso el promedio de varios días es una media: un día excepcional eleva la base durante toda la ventana de promediado, así que cada día normal posterior a uno bueno se lee como una caída.

La mediana de cuatro días equivalentes no tiene ninguno de los dos problemas, y un cambio real y sostenido sigue convirtiéndose en la nueva base en un par de semanas.

Si el espacio de trabajo es demasiado nuevo para tener datos en dos de esas cuatro semanas, la alerta informa not enough history yet y se mantiene en silencio en vez de comparar contra cero.

Alcance (opcional)

Limita la alerta a una parte concreta:

• Entrante: limita por clave de API (token bearer concreto) o endpoint (ruta concreta), o ambos.
• Saliente: limita por URL de webhook. El desplegable se completa con los nodos de webhook activos y en borrador de tus recorridos, para elegir un destino real en vez de escribir una URL.
• Eventos: limita por nombre de evento. El selector usa el vocabulario real de eventos de tu espacio de trabajo: los 200 nombres más frecuentes de los últimos 30 días, con sus recuentos. Déjalo en «todos los eventos» para contarlos todos; se desactiva cuando la métrica es Total de eventos.

Deja el alcance en el valor predeterminado «todos» para evaluar todo el espacio de trabajo.

Vista previa en tiempo real

El pie consulta un endpoint de vista previa con la configuración actual y muestra:

• Se activaría ahora (rojo): el valor actual de la métrica ya cruza el umbral. Sirve para detectar configuraciones demasiado sensibles.
• Correcta (verde): el valor actual está dentro del umbral.
• En pausa (gris): el interruptor Activa (en el paso 3) está apagado, así que no se activará aunque cumpliera la condición.

La vista previa nunca guarda nada ni envía una notificación; solo es una comprobación rápida.

Paso 3: Notificar

Un resumen de revisión oscuro en la parte superior repasa qué estás vigilando («Estás creando una alerta sobre…») e incluye un enlace Editar para volver al paso 1.

Canal

Elige cómo te llegará la alerta cuando se active:

Canal de email (predeterminado)

Campo	Qué hace
Destinatarios de email	Elige miembros entre tu gente, o escribe una dirección externa y pulsa Intro o una coma. Haz clic en ✕ para eliminarla. Se requiere al menos un destinatario. Las direcciones externas no reciben nada hasta que confirman - consulta Las direcciones externas deben confirmar. Una regla creada antes de que las direcciones externas tuvieran que confirmar muestra un aviso con Enviar confirmación (detalles).
	Se envía un mensaje por destinatario en la transición correcta → activada. Mientras la alerta siga activada, los destinatarios reciben un recordatorio de que sigue activa cada 4 horas (3 como máximo por incidente) y un email de Resuelta cuando vuelve a estar correcta.

Canal de webhook

Campo	Qué hace
URL de webhook	Obligatoria. Joryio envía aquí una carga JSON mediante POST cada vez que se activa la alerta.
Secreto de firma	Opcional. Joryio firma cada solicitud con HMAC-SHA256(body) y la envía en la cabecera X-Joryio-Signature, para que el receptor pueda verificar que la llamada procede realmente de Joryio.

Se muestra una vista previa de la carga en un bloque de código oscuro, completada con el nombre y la métrica que acabas de configurar. El canal de webhook envía POST en ambas transiciones (triggered y resolved) para que el receptor pueda relacionar un incidente de principio a fin. Los recordatorios cada 4 horas son solo por email. La entrega se reintenta hasta tres veces con espera exponencial. Consulta el referente de la API de Supervisión para el contrato exacto de la carga.

Periodo de espera y activación

Campo	Qué hace
Periodo de espera	Tiempo mínimo entre nuevas activaciones después de que la métrica vuelva a estar correcta. El valor predeterminado es 10 minutos. Opciones: 5 m, 10 m, 30 m, 1 h.
Activa	Interruptor. Cuando está apagado, la alerta se guarda en estado En pausa: no se evalúa ni se activa.

Ciclo de vida de una alerta

Una vez guardada, cada alerta se encuentra en uno de cuatro estados:

Estado	Aspecto	Significado
Correcta	Etiqueta turquesa	Está vigilando; no hay incumplimiento.
Activada	Etiqueta roja con pulso	La métrica cruzó el umbral y la alerta se activó. Se notificó a los destinatarios. La fila muestra Activa desde con la hora en que empezó el incidente.
Pospuesta	Etiqueta gris	Silenciada temporalmente. Volverá automáticamente a Correcta al expirar el periodo de posposición.
En pausa	Etiqueta gris	Silenciada indefinidamente. No se evaluará ni activará hasta que la reanudes manualmente.

Frecuencia de evaluación

El evaluador de backend se ejecuta cada minuto. La menor duración que se puede elegir en la interfaz es un minuto, por lo que una frecuencia mayor desperdiciaría CPU.

En cada ejecución, para cada alerta activa que no esté pospuesta ni en pausa:

1. Consulta la fuente de la métrica (registro de solicitudes API entrantes, registro de entregas de webhook salientes o tabla de eventos) para la ventana de duración.
2. Compara el valor actual con el umbral. En modo Cambio, también consulta la ventana de comparación: la inmediatamente anterior o la misma ventana de hace 7 días.
3. Si lo cruza → establece el estado en Activada, escribe una fila firing en el Historial y notifica por el canal elegido.
4. Si sigue activada y el canal es email → envía un recordatorio de que sigue activa cuando han pasado 4 horas desde la activación o el recordatorio anterior, 3 como máximo por incidente.
5. Si estaba activada y el valor vuelve a ser correcto → establece el estado en Correcta, marca la fila firing más reciente como resolved con la marca de tiempo resolvedAt y envía un email de Resuelta (canal de email) o un webhook resolved (canal de webhook).

Cómo funciona el periodo de espera

Después de activarse, la alerta no volverá a activarse hasta que transcurra el periodo de espera y la métrica haya vuelto a cruzar el umbral hacia abajo y después vuelva a cruzarlo hacia arriba. Así se evita alertar por cada pequeña variación minuto a minuto mientras el problema persiste.

Posponer o pausar

• Posponer tiene un tiempo definido (1 hora, 4 horas, 24 horas o hasta mañana a las 9:00). La alerta se reanuda automáticamente al terminar la ventana. Úsalo cuando ya conoces el problema y quieres silenciarlo durante 4 horas.
• Pausar es indefinido. La alerta permanece en pausa hasta que hagas clic manualmente en Reanudar. Úsalo para reglas que no son relevantes hoy, por ejemplo durante una ventana de mantenimiento planificada sin tráfico.

Puedes posponer una sola alerta desde el menú ⋯ de su fila o hacer clic en Posponer todas en el banner rojo cuando se activan varias alertas a la vez.

Notificaciones activadas

Email

Cuando se activa una alerta del canal de email, cada miembro de la regla y cada dirección externa confirmada recibe un mensaje con:

• El nombre de la alerta en el asunto, con un icono de alerta como prefijo.
• El valor actual de la métrica, el que incumplió el umbral.
• El umbral que se cruzó.
• La descripción de la alerta, si la configuraste.
• Un enlace a Configuración → Registros y supervisión → Alertas.

Mientras la alerta siga activada, los mismos destinatarios reciben un recordatorio de que sigue activa cada 4 horas, con la hora en que empezó, 3 como máximo por incidente. Cuando vuelve a estar correcta reciben un email de Resuelta. Un incidente nuevo (después de resolverse) empieza la cuenta de nuevo.

Los emails de alerta salen de la dirección de notificaciones de Joryio, no del proveedor de email de tu espacio de trabajo, así que nunca usan tu reputación de envío ni tu cuota, y funcionan tanto si has configurado un proveedor de email como si no.

Webhook

Cuando una alerta del canal webhook cambia de estado, Joryio envía una carga JSON mediante POST a tu URL tanto al activarse como al resolverse. Si configuraste un secreto de firma, verifica la cabecera X-Joryio-Signature (el HMAC-SHA256 hexadecimal en minúsculas del cuerpo sin procesar) antes de confiar en la llamada. La forma exacta de la carga se documenta en el referente de la API de Supervisión.

Historial

La página Historial es el rastro de auditoría. Cada transición (correcta → activada, activada → resuelta) escribe una fila.

Cada fila muestra:

• Hora: cuándo ocurrió la transición, con el tiempo relativo debajo.
• Alerta + etiqueta de estado: Firing, Resolved o Snoozed at fire.
• Instantánea de métrica: el valor que alcanzó la métrica en la transición y el umbral configurado.
• Minigráfico: pequeño gráfico de la métrica alrededor de la transición. Rojo al activarse, turquesa al resolverse y gris si estaba pospuesta.
• Duración: cuánto duró el incidente (Ongoing si sigue activo).
• Destinatarios: quién recibió la notificación, con +N para el resto. Muestra silent en cursiva si nadie fue notificado, por ejemplo si la alerta estaba pospuesta en ese momento.

Filtros

Tres filtros en la parte superior de la página:

• Alerta: muestra los eventos de una sola regla de alerta.
• Estado: Firing now, Resolved o Snoozed at fire.
• Periodo: 24h, 7d, 30d, 90d.

Las cuatro tarjetas de estadísticas sobre la cronología agregan los eventos visibles, tras aplicar los filtros:

Tarjeta	Qué cuenta
Firing now	Incidentes abiertos: la métrica sigue incumpliendo el umbral.
Resolved (7d)	Incidentes que se resolvieron solos o se confirmaron en los últimos 7 días.
Mean time to resolve	Duración media de los incidentes resueltos.
Notifications sent	Total de destinatarios notificados en todos los eventos de la ventana.

Qué se mide

Las métricas proceden de tres flujos de datos de solo anexado que se completan automáticamente.

Registro de solicitudes API entrantes

• Qué incluye: todas las solicitudes autenticadas con clave de API a la API REST de Joryio: marca de tiempo, organización, espacio de trabajo, prefijo de la clave de API, método HTTP, endpoint canónico (por ejemplo, /users/:id), código de estado y duración.
• Qué no incluye: tráfico del panel (llamadas autenticadas por JWT desde la interfaz de Joryio), comprobaciones de estado ni rutas solo internas.

Registro de entregas de webhook salientes

• Qué incluye: cada intento de webhook enviado desde un nodo de webhook de un recorrido de usuario: marca de tiempo, organización, espacio de trabajo, lienzo, URL, estado de respuesta (o 0 para errores de transporte como tiempos de espera), duración y número de intento.
• Qué no incluye: webhooks enviados antes de desplegar esta función; los trabajos antiguos en cola no incluyen los metadatos de tenant necesarios y el registrador los omite sin error.

Eventos

• Qué incluye: cada evento de cliente registrado desde tu SDK o aplicación, por nombre de evento y usuario. Es la misma tabla events que consulta el resto de la plataforma.

Controles de registro y conservación

Tanto el registro de solicitudes API entrantes como el de entregas de webhook salientes se pueden configurar por organización; el personal de Joryio los gestiona desde la consola de administración:

• Interruptor de desactivación: cada flujo de registro se puede activar o desactivar de forma independiente para una organización. Cuando está desactivado, no se escriben filas y las métricas de esa dirección dejan de actualizarse. Ambos están activados de forma predeterminada.
• Conservación: cada flujo tiene su propia ventana de conservación entre 7 y 365 días (el valor predeterminado es 90). Las filas se eliminan automáticamente al superar la conservación de su organización.

Si tus alertas dejan de evaluarse repentinamente en una dirección, confirma con el administrador de Joryio que el flujo de registro correspondiente siga activado.

Alertas automáticas de salud (sin configuración)

Además de las alertas que configuras tú, Joryio vigila continuamente cada espacio de trabajo para detectar fallos de integración. No requiere configuración:

• Interrupción total: los eventos fluían y de repente se detuvieron por completo (una clave de SDK inactiva, un despliegue roto o un fragmento eliminado). Se genera como alerta crítica.
• Caída sostenida: el volumen de eventos cae muy por debajo de la línea de base de varios días del espacio de trabajo. Se genera como advertencia.
• Detección por evento: los eventos más relevantes, por ejemplo purchase o page_view, se vigilan por separado; así se detecta un único paso roto del embudo aunque el volumen total parezca normal.
• Colisiones de mensajes: tus propios journeys y campañas llegan a las mismas personas al mismo tiempo. Se emite como aviso cuando, en los últimos 7 días, al menos el 25% de quienes recibieron un mensaje recibieron dos o más el mismo día (y al menos 50 personas recibieron un mensaje). La alerta indica la proporción, cuántas de ellas dentro de una hora y las campañas o journeys más implicados. Se resuelve sola cuando la proporción vuelve a bajar del umbral. No se bloquea nada. La proporción y el mínimo puedes cambiarlos en Ajustes → Monitorización → Alertas; el 25% es el valor por defecto porque un email y un push a la misma persona el mismo día cuentan como colisión, y muchos programas lo hacen a propósito.
• Habituales en silencio: no es una alerta sino el umbral de la idea "habituales en silencio" del panel de inicio, que se guarda aquí junto a la alerta de colisiones porque es el mismo tipo de ajuste. La idea aparece cuando los clientes habituales cuya marca de compra atrasada se activó esta semana llegan al menos al mínimo (por defecto 25) o a la proporción de tus habituales activos (por defecto 2%), lo que sea mayor. Edita ambos en Ajustes → Monitorización → Alertas; la guía del panel describe la tarjeta.

Cuando algo falla verás un banner en la página Supervisión, una notificación en la campana y recibirás un email con un breve diagnóstico de IA: qué es lo que probablemente falló y qué revisar primero. El email llega a los propietarios y administradores de la cuenta, y a los miembros cuyo acceso les permite cambiar la configuración de ese espacio de trabajo, una vez por incidente. Si ya configuraste una alerta propia de Total events o Unique users para el espacio de trabajo, Joryio suprime el email duplicado: tu alerta avisa a sus propios destinatarios.

Descartar: puedes descartar una alerta automática desde el banner; con ello reconoces este incidente y lo ocultas. Si la integración se recupera y falla otra vez más adelante, se genera una nueva alerta. La recuperación también resuelve la alerta automáticamente.

Seguridad de periodo de espera y límite de frecuencia

Las alertas se activan como máximo una vez por periodo de espera. Si una métrica sigue incumpliendo el umbral durante horas, recibirás la primera notificación y después un recordatorio como máximo cada 4 horas (3 como máximo), no 60 por hora, y un email cuando se resuelva. El contador de espera se restablece cuando la métrica vuelve a estar correcta.

Si pospusiste una alerta, las activaciones que ocurran durante la posposición seguirán escribiendo una fila en el Historial para que puedas ver lo que te perdiste, pero no se envía ninguna notificación y la columna Destinatarios muestra silent (snoozed).

En un espacio de trabajo de demostración con las conexiones externas cerradas, las alertas se siguen evaluando y siguen apareciendo en la app - la campana, el estado de la alerta, el Historial (la columna Destinatarios muestra silent) y el aviso de seguimiento de eventos - pero no sale ningún email ni webhook, ni para las reglas de alerta ni para la detección automática de problemas de seguimiento de eventos. En cuanto Joryio abre la demo a conexiones externas, las alertas notifican como siempre.

Limitaciones

• Canales: se admiten email y webhook. No hay un canal nativo de Slack; dirige las alertas webhook de Joryio a Slack mediante un webhook entrante de Slack o usa integraciones de incidentes basadas en email, como PagerDuty.
• Páginas de detalle por evento: el botón Ver detalles de las filas de Historial es visible, pero actualmente no realiza ninguna acción.