Alertes

La plateforme se surveille elle-même avec 48 règles, et annonce ce qu'elles trouvent dans le Studio, par e-mail ou vers un webhook.

Vous n'interrogez rien, et rien ne nous est remonté. Chaque règle lit la plateforme à sa propre cadence et compare ce qu'elle mesure à un seuil d'avertissement et à un seuil d'alerte. Les 8 règles de type state n'ont pas de seuil : elles disent seulement si quelque chose est en panne. Un changement de gravité est annoncé, retour à la normale compris, et l'annonce est répétée à un intervalle propre à la règle tant qu'elle reste déclenchée.

Les quatre familles

Famille	Règles	Ce qu'elle surveille
platform	14	Boucles de redémarrage, erreurs de la base de données, de Redis et du stockage objet, requêtes lentes, files qui s'accumulent, âge de la boîte d'envoi et échecs de son relais, services annexes qui refusent, courrier non configuré ou en échec, échecs d'export des traces, limitation de débit
runs	13	Taux d'échec, exécutions perdues, reprises en échec, refus, exécutions en sommeil sur un quota, durée, attente en file, boucles interrompues, débordement de contexte, validations en attente, questions au visiteur restées sans réponse, déploiements devenus silencieux, baux d'exécution perdus
providers	9	Tentatives en échec, crédit épuisé, tests de connexion en échec ou périmés, dérive de coût, jetons par exécution, latence, modèles inconnus, modèles de repli inutilisables
security	12	Connexions en échec, clés d'API refusées, CSRF rejetés, refus RBAC, sorties de webhook bloquées, contenu non fiable, sorties d'agent bloquées, accès à la console d'exploitation, clé de scellement refusée, échecs d'écriture de l'audit, retours SSO rejetés, fournisseur d'identité injoignable

Une famille, c'est la façon dont l'écran regroupe les règles. Chaque règle porte une clé stable écrite family.subject.outcome, et cette clé ne change jamais. Les règles platform et security sont actives par défaut. Les règles runs et providers restent inactives tant que personne ne les active, avec Créer une alerte sur l'écran Alertes, sous Surveillance.

Gravités

Après chaque évaluation, une règle est ok, warning ou alert. Un taux dont la fenêtre contenait trop peu d'échantillons pour juger est no_data, et une règle pas encore évaluée est unknown : les deux sont enregistrées et jamais annoncées. L'écran Alertes affiche une règle jamais évaluée comme En attente de données, pas comme en bonne santé.

Où part une alerte

Trois canaux, choisis règle par règle. Un seul a une adresse que vous déclarez. C'est voulu : les deux autres savent déjà où aller.

Canal	Où cela part	Vous configurez
studio	L'écran Alertes, et un compteur sur son entrée de menu	Rien
mail	Les propriétaires et administrateurs actifs de l'organisation, ou les opérateurs de la plateforme pour les règles propres au déploiement	Un serveur de messagerie qui fonctionne
webhook	Une URL, déclarée une fois par périmètre	L'URL

Le canal webhook

Un périmètre déclare une URL, et Rikoo y envoie du JSON par un POST à chaque annonce. Il n'y a aucun abonnement à gérer, aucun catalogue d'événements où choisir, et aucune signature. Ce qui circule, c'est l'annonce elle-même : la règle, la gravité annoncée et depuis quand, la dernière mesure et le moment où elle a été prise, les seuils et la fenêtre, plus un champ text qui dit la même chose en une phrase.

Son premier champ est text, à dessein. Un webhook entrant Slack est une URL comme une autre : pointer un périmètre dessus fait arriver les alertes dans un canal Slack sans intégration, sans jeton de bot et sans espace de travail à connecter. Rikoo garde Slack comme destination et a cessé de le maintenir comme intégration d'alertes.

{
  "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
}

Le corps est construit champ par champ : aucun contenu d'exécution, et jamais une ligne de la base de données recopiée dedans. Un destinataire qui reçoit deux fois le même transitionKey a sous les yeux une seule annonce livrée deux fois.

Livrée veut dire que le point d'accès a répondu

Une livraison webhook est marquée envoyée quand votre point d'accès répond 2xx. Toute autre réponse est retentée, jusqu'à 5 tentatives. Pour le courrier, envoyé veut dire que les messages ont été remis à la file d'envoi, pas qu'ils sont arrivés : aucun système ne peut promettre qu'un message a atteint son lecteur.

L'adresse est gardée

Une URL de webhook est saisie à la main : elle est donc traitée comme une entrée non fiable. Chaque livraison passe par la garde anti-SSRF, qui vérifie l'adresse vers laquelle l'hôte résout réellement et ne suit une redirection que vers une adresse qu'elle accepterait aussi. Un webhook visant un point de métadonnées en lien local est refusé d'emblée.

Un refus de cette garde est lui-même annoncé, sous security.webhook_egress_blocked. Une adresse qui résout là où elle ne doit pas, c'est à quoi ressemble d'ici une tentative d'atteindre votre réseau interne : elle mérite une règle plutôt qu'une erreur silencieuse.

Testez la destination, et fiez-vous au canal

Enregistrer une URL n'envoie rien, car le serveur d'API n'appelle jamais l'extérieur. Envoyer un test met en file une vraie livraison, avec le même corps qu'une vraie annonce. La preuve, c'est le message qui arrive dans le canal Slack ou dans le journal du service destinataire, pas une coche verte dessinée par la plateforme.

Ce qu'une règle vous laisse changer

Quatre réglages, pas davantage : si elle est active, ses deux seuils et ses canaux. Tout le reste est le comportement de la règle, figé dans le produit, et c'est ce qui rend deux déploiements comparables.

• Fenêtre et cadence. Jusqu'où une évaluation regarde en arrière, et à quelle fréquence elle s'exécute.
• Échantillons minimum. Un taux refuse de juger une fenêtre qui contient trop peu d'échantillons. Une exécution en échec sur une n'est pas un taux d'échec de 100 %, c'est une exécution en échec.
• Renotification. Combien de temps avant que la même gravité soit annoncée de nouveau tant qu'une règle reste déclenchée. Acquitter la fait taire jusqu'au prochain changement de gravité.
• Politique d'absence de données. Ce que vaut une fenêtre vide, qui n'est pas la même réponse pour une profondeur de file et pour un battement de cœur.

La famille security ne peut pas être désactivée

Ses 12 règles refusent d'être désactivées : l'API rejette la tentative. Vous restez libre d'ajuster leurs seuils, car un seuil est un jugement sur votre trafic, mais un déploiement qui pourrait faire taire ses propres connexions en échec aurait un audit qui ne veut rien dire.

Deux périmètres

Une règle appartient soit au déploiement, lue par un opérateur de la plateforme, soit à une organisation : 20 règles sont celles du déploiement, 28 appartiennent à chaque organisation. Les deux vivent dans la même table, distinguées par le fait qu'elles portent ou non une organisation, et c'est la politique d'isolation des locataires qui donne du mordant à cette distinction : une ligne qui n'appartient à aucune organisation n'est atteignable par aucune connexion de locataire. L'écran Alertes du Studio affiche les règles de l'organisation.