Un seuil d’alerte dit à partir de quand un écart de contrôle devient un message à un humain. Sans seuil, chaque essai raté sonne. Avec un seuil trop large, une panne réelle attend trop longtemps. On règle trois choses, séparément : combien d’échecs de suite, à partir de quel temps de réponse, et quand on annonce le retour à la normale.
Échecs consécutifs
Le premier filtre porte sur la disponibilité au sens strict : code inattendu, échec DNS ou TLS, délai dépassé, contenu attendu absent. Un seul essai dans ce cas ne prouve pas que les visiteurs sont touchés. Le chemin entre le point de mesure et votre origine a ses propres accrocs.
Demandez deux ou trois échecs d’affilée avant d’alerter. Avec un contrôle toutes les cinq minutes, trois échecs représentent environ dix à quinze minutes d’écart confirmé, pas trois secondes. Si ce délai est trop long pour une page de paiement, raccourcissez l’intervalle de contrôle plutôt que d’alerter au premier raté : vous gardez le filtre, vous réduisez l’attente.
Le contenu absent se traite comme un échec, au même titre qu’un 500. Un 200 dont le formulaire a disparu ne doit pas bénéficier d’un seuil plus laxiste sous prétexte que « le site répond ».
Quand vous avez plusieurs points de mesure, le seuil se combine à la règle de majorité du monitoring multi-localisations : des échecs consécutifs sur une seule sonde ne valent pas des échecs consécutifs sur la majorité.
Le temps de réponse, URL par URL
Le temps de réponse n’a pas de plafond universel. Une page servie depuis un cache peut répondre en une fraction de seconde. Une page qui interroge un outil métier peut mettre deux secondes en régime normal. Le même seuil en millisecondes alertera toute la journée sur la seconde et jamais sur la première, ou l’inverse.
Relevez, sur l’historique des essais réussis, l’ordre de grandeur habituel de cette URL. Placez le seuil clairement au-dessus, de façon à ignorer la variation ordinaire et à attraper un palier (serveur saturé, base sans cache, appel tiers bloqué). Si vous ne connaissez pas encore l’habitude, n’activez pas l’alerte de lenteur la première semaine : collectez, puis fixez.
La lenteur et l’échec HTTP ne doivent pas partager le même canal si l’équipe ne les traite pas de la même façon. Un 503 réveille l’astreinte. Un dépassement de délai modéré peut attendre un créneau de jour, surtout s’il est isolé. Écrire cette différence évite de désensibiliser tout le monde.
Retour à la normale et silence voulu
Annoncez la fin d’incident après au moins deux succès consécutifs. Un succès unique au milieu d’une panne, suivi d’un nouvel échec, produirait deux alertes d’ouverture et une fausse clôture. Le même identifiant d’incident relie l’ouverture et la clôture, ce qui rejoint le fonctionnement d’un webhook.
Prévoyez une fenêtre de silence pour les maintenances annoncées. Elle supprime l’alerte, pas le contrôle : les essais restent dans l’historique, marqués comme prévus. Une fenêtre qui déborde jusqu’au lendemain matin avale une vraie panne. Tenez-la au créneau du déploiement, puis laissez les seuils reprendre.
Relisez les seuils après un mois de messages. Trop d’alertes closes en « rien à faire » veut dire que le nombre d’échecs exigés est trop bas, ou que le plafond de temps est dans la variation normale. Zéro alerte sur un site que vous savez avoir eu un 500 veut dire l’inverse. SiteGarde applique les seuils que vous avez écrits : un réglage par défaut raisonnable ne connaît pas votre page la plus lente.