Alertas
La plataforma se vigila a sí misma con 48 reglas y anuncia lo que encuentran en el Studio, por correo electrónico o a un webhook.
Usted no consulta nada, y a nosotros no se nos comunica nada. Cada regla lee la plataforma a su propia cadencia y compara lo que mide con un umbral de advertencia y un umbral de alerta. Las 8 reglas de tipo state no tienen umbral: solo dicen si algo está averiado. Se anuncia cada cambio de gravedad, incluida la vuelta a la normalidad, y el anuncio se repite a un intervalo propio de la regla mientras siga disparada.
Las cuatro familias
| Familia | Reglas | Qué vigila |
|---|---|---|
| platform | 14 | Bucles de reinicio, errores de la base de datos, de Redis y del almacenamiento de objetos, consultas lentas, colas acumuladas, antigüedad de la bandeja de salida y fallos de su relé, servicios auxiliares que rechazan, correo sin configurar o fallando, fallos de exportación de trazas, limitación de tasa |
| runs | 13 | Tasa de fallo, ejecuciones perdidas, reanudaciones fallidas, rechazos, ejecuciones dormidas por una cuota, duración, espera en cola, bucles detenidos, desbordamiento de contexto, aprobaciones en espera, preguntas al visitante sin respuesta, despliegues que se han quedado en silencio, concesiones de ejecución perdidas |
| providers | 9 | Intentos fallidos, crédito agotado, pruebas de conexión fallidas o desfasadas, desviación de coste, tokens por ejecución, latencia, modelos desconocidos, modelos de respaldo inutilizables |
| security | 12 | Inicios de sesión fallidos, claves de API denegadas, CSRF rechazados, rechazos de RBAC, salidas de webhook bloqueadas, contenido no confiable, respuestas de agente bloqueadas, accesos a la consola de operación, clave de sellado rechazada, fallos de escritura de la auditoría, retornos de SSO rechazados, proveedor de identidad inalcanzable |
Una familia es la manera en que la pantalla agrupa las reglas. Cada regla lleva una clave estable escrita family.subject.outcome, y esa clave no cambia nunca. Las reglas platform y security están activas por defecto. Las reglas runs y providers permanecen inactivas hasta que alguien las active, con Create alert (crear una alerta) en la pantalla Alerts, bajo Monitor.
Gravedades
Tras cada evaluación, una regla está en ok, warning o alert. Una tasa cuya ventana contenía demasiado pocas muestras para juzgar queda en no_data, y una regla aún no evaluada está en unknown: ambas se registran y nunca se anuncian. La pantalla Alerts muestra una regla que nunca se ha evaluado como Awaiting data (a la espera de datos), no como sana.
Adónde va una alerta
Tres canales, elegidos regla por regla. Solo uno tiene una dirección que usted declara. Es a propósito: los otros dos ya saben adónde ir.
| Canal | Adónde va | Usted configura |
|---|---|---|
| studio | La pantalla Alerts y un contador en su entrada de menú | Nada |
| Los propietarios y administradores activos de la organización, o los operadores de la plataforma para las reglas propias del despliegue | Un servidor de correo que funcione | |
| webhook | Una URL, declarada una vez por ámbito | La URL |
El canal webhook
Un ámbito declara una URL, y Rikoo le envía un JSON (POST) con cada anuncio. No hay suscripción que gestionar, ni catálogo de eventos donde elegir, ni firma. Lo que viaja es el anuncio mismo: la regla, la gravedad anunciada y desde cuándo, la última medida y cuándo se tomó, los umbrales y la ventana, más un campo text que dice lo mismo en una frase.
Su primer campo es text, a propósito. Un webhook entrante de Slack es una URL como cualquier otra: apuntar un ámbito hacia ella hace que las alertas lleguen a un canal de Slack sin integración, sin token de bot y sin espacio de trabajo que conectar. Rikoo conserva Slack como destino y dejó de mantenerlo como integración de alertas.
{
"text": "ALERT: runs.failure_rate is sounding on this organisation. Too large a share of runs is failing. Last measure: 0.23.",
"ruleId": "0b7e5c52-8d1f-4a52-9d0e-3c6f1a2b4d77",
"detector": "runs.failure_rate",
"scope": "org",
"orgId": "5a0d9f3e-2c41-4b8e-a7f6-91e2d3c4b5a6",
"channel": "webhook",
"transitionKey": "alert@1789805642511",
"severity": "alert",
"renotification": null,
"since": "2026-09-19T08:14:02.511Z",
"measure": 0.23,
"measuredAt": "2026-09-19T08:14:02.511Z",
"warningThreshold": 0.05,
"alertThreshold": 0.2,
"windowSeconds": 3600
}
El cuerpo se construye campo a campo: ningún contenido de ejecución, y nunca una fila de la base de datos copiada en él. Un receptor que recibe dos veces el mismo transitionKey tiene ante sí un único anuncio entregado dos veces.
Una entrega por webhook se marca como enviada cuando su endpoint responde 2xx. Cualquier otra respuesta se reintenta, hasta 5 intentos. En el correo, enviado significa que los mensajes se entregaron a la cola de envío, no que hayan llegado: ningún sistema puede prometer que un mensaje llegó a su lector.
La dirección está vigilada
Una URL de webhook se escribe a mano, así que se trata como entrada no confiable. Cada entrega pasa por la protección anti-SSRF, que comprueba la dirección a la que el host resuelve realmente y solo sigue una redirección hacia una dirección que también aceptaría. Un webhook dirigido a un endpoint de metadatos de enlace local se rechaza antes de salir.
Un rechazo de esa protección se anuncia a su vez, bajo security.webhook_egress_blocked. Una dirección que resuelve donde no debe es el aspecto que tiene desde aquí un intento de alcanzar su red interna: merece una regla y no un error silencioso.
Guardar una URL no envía nada, porque el servidor de API nunca llama al exterior. Send a test (enviar una prueba) encola una entrega real, con el mismo cuerpo que un anuncio real. La prueba es el mensaje que llega al canal de Slack o al registro del servicio receptor, no una marca verde dibujada por la plataforma.
Qué le deja cambiar una regla
Cuatro ajustes, y no más: si está activa, sus dos umbrales y sus canales. Todo lo demás es el comportamiento de la regla, congelado en el producto, que es lo que hace comparables dos despliegues.
- Ventana y cadencia. Hasta dónde mira hacia atrás una evaluación y con qué frecuencia se ejecuta.
- Muestras mínimas. Una tasa se niega a juzgar una ventana con demasiado pocas muestras. Una ejecución fallida de una no es una tasa de fallo del 100 %, es una ejecución fallida.
- Renotificación. Cuánto tiempo pasa antes de que la misma gravedad vuelva a anunciarse mientras una regla sigue disparada. Acknowledge (acusar recibo) la silencia hasta el siguiente cambio de gravedad.
- Política de ausencia de datos. Cuánto vale una ventana vacía, que no es la misma respuesta para una profundidad de cola que para un latido.
Sus 12 reglas se niegan a ser desactivadas: la API rechaza el intento. Puede seguir ajustando sus umbrales, porque un umbral es un juicio sobre su tráfico, pero un despliegue que pudiera silenciar sus propios inicios de sesión fallidos tendría una auditoría que no significa nada.
Dos ámbitos
Una regla pertenece o bien al despliegue, leída por un operador de la plataforma, o bien a una organización: 20 reglas son las del despliegue y 28 pertenecen a cada organización. Ambas viven en la misma tabla, distinguidas por si llevan o no una organización, y es la política de aislamiento de inquilinos la que da fuerza a esa distinción: una fila que no pertenece a ninguna organización no es alcanzable por ninguna conexión de inquilino. La pantalla Alerts del Studio muestra las reglas de la organización.