Alertes

Un moniteur enregistre le statut, mais il ne viendra pas vous chercher quand quelque chose casse — c'est le rôle des alertes. Une règle d'alerte surveille un moniteur et, lorsque son statut change, envoie une notification vers les canaux que vous choisissez. Cette page vous montre comment en configurer une.

Il vous faut d'abord un moniteur — voir créer un moniteur — et au moins un canal de notification vers lequel envoyer l'alerte.

Comment fonctionnent les alertes

Une règle d'alerte relie deux choses :

1. Un déclencheur — un changement de statut d'un moniteur, par exemple le passage en down, en dégradé, ou le rétablissement en up.
2. Un ou plusieurs canaux — où la notification est envoyée (Email, Slack, Discord, Webhook).

Quand le statut du moniteur change d'une manière surveillée par la règle, Servor envoie la notification. Comme les changements de statut sont confirmés avant d'être validés, les alertes ne se déclenchent pas sur des soubresauts passagers — uniquement sur les changements qui tiennent réellement.

Créer une règle d'alerte

Garder des alertes utiles

L'objectif est d'être prévenu des vrais problèmes, et de rien d'autre. Quelques habitudes aident :

• Alertez sur down pour l'essentiel, sur dégradé pour les signaux précoces. Réservez les notifications pressantes aux pannes ; traitez le dégradé comme un avertissement.
• Envoyez au bon endroit. Routez les pannes visibles par les clients vers un canal suivi par l'équipe d'astreinte, pas vers un canal général déjà surchargé.
• Attention au cooldown. Les canaux ont un cooldown qui limite la fréquence des relances, pour qu'un moniteur instable ne vous mitraille pas.
• Ne suralertez pas. Dix moniteurs qui vous notifient tous pour une même cause racine, c'est du bruit. Voir bonnes pratiques de surveillance.

Heures de silence et escalade

Deux réglages par règle affinent quand et jusqu'où une alerte va :

• Heures de silence — une fenêtre (dans le fuseau horaire de votre choix) pendant laquelle la règle ne notifie pas. Parfait pour taire les alertes non critiques la nuit ; la fenêtre peut chevaucher minuit (ex. 22:00 → 07:00). L'escalade ci-dessous n'est pas silencée : un vrai problème qui dure finit toujours par sonner.
• Escalade — si un moniteur reste down au-delà d'un délai (ex. 15 min), Servor prévient un second groupe de canaux. C'est le filet de l'astreinte : si personne n'a réagi, on monte d'un cran. Un rétablissement avant l'échéance annule l'escalade automatiquement — vous n'avez rien à faire.

Faire taire un moniteur pendant un déploiement

Une intervention planifiée déclenche de vraies alertes pour de fausses raisons : le service redémarre, le moniteur le voit tomber, et l'astreinte est réveillée pour un arrêt que vous avez vous-même provoqué.

Depuis la page d'un moniteur, Mettre en sourdine le silence pour une durée bornée. Pendant ce temps, le check n'est pas exécuté du tout : pas d'alerte, pas de faux incident ouvert sur votre status page, et pas de trou artificiel dans vos statistiques d'uptime causé par des échecs que vous saviez à l'avance.

La sourdine expire d'elle-même. C'est délibéré : un moniteur silencé indéfiniment est un moniteur que personne ne pense à réactiver, et c'est une panne plus grave que la fausse alerte qu'on cherchait à éviter. Si vous voulez vraiment arrêter un moniteur pour de bon, désactivez-le — au moins, l'écran le dit.

À la réactivation, le moniteur repasse en inconnu, jamais directement en opérationnel : aucun check n'a tourné pendant la sourdine, donc le déclarer sain serait affirmer quelque chose que personne n'a vérifié. Le prochain check tranche, dans l'intervalle configuré.

Étapes suivantes