L’alerte parvient à la bonne personne, pas dans le bruit.
Votre stack de supervision déclenche un webhook ; SendNomi route l’alerte vers la bonne équipe selon la sévérité et le label, distribue les synthèses selon un calendrier, et conduit la réponse aux incidents avec une traçabilité de bout en bout. L’e-mail d’exploitation est soit du bruit, soit une bouée de sauvetage — la différence tient à la règle de routage.
Pas du bruit — un seul e-mail à la bonne équipe.
Un dépassement de seuil Prometheus ou une alarme Grafana arrive sous forme de webhook ; la règle examine la sévérité (P1–P3) et les labels pour désigner l’équipe cible. L’ingénieur d’astreinte reçoit un e-mail mis en forme avec un résumé de contexte, et chaque alerte est consignée dans une trace horodatée. SendNomi se place devant votre stack de supervision existante — aucun SDK requis.
- Événement Un dépassement de seuil ou une alarme arrive sous forme de webhook.
POST /webhooks/alerts - Règle La correspondance sévérité + label désigne l’équipe cible.
severity=P1 → team: on-call - Envoi Un e-mail d’alerte mis en forme avec un résumé de contexte.
template: alert-context - Trace Qui, quand, pourquoi — un journal horodaté.
retention: 12 months
Le bruit se dépose dans un rapport chaque matin.
Les synthèses quotidiennes et hebdomadaires se génèrent d’elles-mêmes sur un déclencheur cron : un rapport basé sur un modèle part vers l’équipe en un seul e-mail, sans compilation manuelle. Une nouvelle route, une fenêtre de maintenance ou une note de version emprunte le même canal — publiée en un clic vers une audience définie par rôles, pour que toute l’équipe soit informée au même moment.
- Synthèse quotidienne des logs Un rapport basé sur un modèle parvient à l’équipe chaque matin.
trigger: cron · daily - Synthèse hebdomadaire Les métriques de la semaine fusionnent en un seul e-mail.
trigger: cron · weekly - Annonce système Déploiement, maintenance, changement de route — publié en un clic.
target: role-based
Un incident n’est pas seulement résolu ; il est annoncé, suivi, analysé.
Dès l’ouverture d’une alarme P1, l’ingénieur d’astreinte dispose du résumé de contexte ; les parties prenantes reçoivent le statut depuis une source unique, et les notes d’avancement partent d’elles-mêmes à intervalles définis pendant la résolution. À la clôture de l’incident, la fenêtre d’impact et le résumé sont distribués ; la chronologie de la revue post-incident se remplit d’elle-même à partir du journal d’audit. Aucune étape n’échappe à la trace.
- DÉTECTION Incident ouvert
Alarme P1 ; l’ingénieur d’astreinte reçoit immédiatement un e-mail avec le résumé de contexte.
- ANNONCE Information des parties prenantes
Les équipes concernées et les responsables reçoivent le statut depuis une source unique.
- MISE À JOUR Note d’avancement
Des mises à jour de statut automatiques à intervalles définis pendant la résolution.
- CLÔTURE Note de résolution
La fenêtre d’impact et un court résumé sont envoyés à toutes les parties prenantes.
- REVUE Rapport post-incident
La chronologie se remplit d’elle-même à partir du journal d’audit.
Les premières secondes d’une alerte P1.
Comment une alerte entre sous forme de webhook et devient une trace exploitable dans une configuration représentative — les latences correspondent à une configuration typique et varient selon la complexité des règles.
L’e-mail d’alerte contient un résumé de contexte : quel service, quel seuil, depuis quand.
Votre premier envoi en quelques minutes.
Créez votre compte gratuit — 500 envois par mois, sans limite de durée.