Clustraly
Intelligence des erreurs & RGPD

Alerting multi-canal : sachez à l'instant qu'une erreur frappe (notif, email, webhook)

Alerting multi-canal (notif/email/webhook) une fonctionnalité du module Intelligence des erreurs & RGPD de Clustraly. L'alerting multi-canal envoie une alerte notification, email et webhook signé dès qu'une erreur nouvelle, régressée, critique ou en pic survient.

Recevez l'alerte au moment où une erreur compte notification admin, email ou webhook signé avec un plancher de sévérité et un throttle qui coupent le bruit.

Réagir à temps

Sachez qu'une erreur frappe avant vos utilisateurs

Vous n'avez plus à surveiller la console en continu. Dès qu'un incident mérite votre attention, Clustraly pousse l'alerte vers vos canaux et vous décidez de la suite.

Les alertes se déclenchent sur quatre évènements : une erreur nouvelle, une régression, un pic soudain ou une erreur critique. Vous choisissez lesquels comptent via error_intel.alert_on.

  • Déclenchement sur new, regression, spike et critical
  • Évènements activables un par un
  • Aucune surveillance manuelle requise
Trois canaux

Une notification admin, un email et un webhook au choix

Chaque alerte peut emprunter trois chemins : une notification admin persistante diffusée dans votre back-office, un email vers l'adresse de votre équipe, et un webhook sortant vers vos systèmes.

L'email part en file d'attente (Mailer::queue) pour ne jamais bloquer la capture, et l'adresse destinataire se règle simplement dans error_intel.alert_email.

  • Notification admin persistante et diffusée
  • Email asynchrone en file d'attente
  • Adresse destinataire configurable
Webhook signé

Branchez vos alertes sur vos propres outils, en confiance

Le webhook sortant porte le nom d'évènement error.{trigger} et part signé via le WebhookService. Votre endpoint vérifie la signature avant d'agir : vous savez que l'appel vient bien de votre instance.

À vous de router ensuite l'alerte où vous le souhaitez dans vos systèmes l'IA propose l'évènement, vous décidez du traitement.

  • Webhook sortant signé via WebhookService
  • Évènement nommé error.{trigger}
  • Signature vérifiable côté récepteur
Le bon signal

Alerté sur les régressions et les pics, pas sur le bruit

Une régression rouvre un groupe déjà résolu, un pic marque une flambée soudaine d'occurrences : ce sont exactement les moments où il faut agir. L'alerting cible ces évènements plutôt que le flot ordinaire.

Un plancher de sévérité écarte les alertes « new » et « spike » de niveau warning le bruit CSP typique ne vous dérange pas pour rien.

  • Alerte sur régression et pic d'occurrences
  • Plancher de sévérité contre le bruit warning
  • Bruit CSP filtré par défaut
Garde-fous

Un anti-spam intégré pour ne jamais crouler sous les alertes

Chaque groupe est limité dans le temps : Clustraly compare la dernière alerte envoyée à un délai d'étouffement (900 secondes par défaut) avant d'en renvoyer une. Une vérification du taux de pics complète ce garde-fou.

L'ensemble reste conditionné par votre configuration : rien ne part tant que vous ne l'avez pas activé.

  • Throttle par groupe (défaut 900 s)
  • Contrôle du taux de pics (spike_per_min)
  • Entièrement conditionné par votre config
Pourquoi ça compte

L'IA propose l'alerte, vous gardez la main

Clustraly détecte, hiérarchise et vous prévient sur le canal de votre choix. Ce qui se déclenche, vers qui et à quelle fréquence tout reste sous votre configuration.

FAQ

Questions fréquentes

Sur quels évènements l'alerting se déclenche-t-il ?
Sur quatre types d'évènements erreur nouvelle (new), régression, pic (spike) et erreur critique que vous activez individuellement via error_intel.alert_on.
Comment éviter d'être submergé d'alertes ?
Chaque groupe d'erreurs est limité par un délai d'étouffement (900 s par défaut) et par un contrôle du taux de pics ; un plancher de sévérité écarte en plus le bruit warning, comme les rapports CSP.
Le webhook d'alerte est-il sécurisé ?
Oui : le webhook sortant part signé via le WebhookService sous l'évènement error.{trigger}, ce qui permet à votre système récepteur de vérifier l'authenticité de l'appel avant d'agir.
Puis-je choisir où arrivent les emails d'alerte ?
Oui : l'email d'alerte part de façon asynchrone (Mailer::queue) vers l'adresse définie dans error_intel.alert_email, sans jamais bloquer la capture des erreurs.
Prêt à commencer ?

Ne découvrez plus vos incidents trop tard

Activez l'alerting multi-canal et laissez Clustraly vous prévenir par notification, email ou webhook signé au bon moment, sur le bon canal, sans bruit inutile. Vous gardez toujours la décision finale.