Ce qui doit déclencher une alerte de panne
Commencez par les échecs que les visiteurs ressentiraient directement : la page d’accueil ne répond pas, le chemin de connexion ou de checkout renvoie une erreur, l’endpoint API dont dépend un autre système échoue, le DNS ne résout plus, ou le certificat TLS est invalide ou assez proche de l’expiration pour demander une action.
Évitez d’alerter sur chaque requête échouée isolée. Un seul accroc réseau depuis une probe location peut être du bruit. Pour la plupart des sites, une meilleure règle est deux ou trois échecs consécutifs, de préférence confirmés depuis plus d’une probe location, avant d’ouvrir un incident.
Qui doit recevoir l’alerte en premier
Envoyez la première alerte à la personne qui peut réellement commencer le correctif : le fondateur, le freelance en maintenance, le canal support de l’agence ou l’ingénieur d’astreinte. Une boîte partagée ou un canal Slack convient seulement si quelqu’un est responsable de le surveiller.
Si personne ne possède la destination, l’alerte n’existe pas en pratique. Le site reste découvert d’abord par un client ; l’outil de monitoring ne crée qu’un enregistrement horodaté que personne n’a vu.
Un calendrier pratique de relance et d’escalade
Pour un site client normal, vérifiez toutes les 5 minutes, exigez un petit seuil d’échecs consécutifs et alertez immédiatement une fois ce seuil franchi. Cela détecte le vrai downtime dans une fenêtre prévisible sans appeler quelqu’un pour chaque échec réseau transitoire.
L’escalade doit suivre le risque métier. Un site vitrine peut prévenir d’abord par email. Un tunnel d’achat, une API payante ou un site client sous contrat de maintenance doit aller vers un canal plus rapide comme Slack, Discord ou un webhook dans le système déjà surveillé par l’équipe.
Un texte d’alerte qui accélère la réponse
Une alerte utile dit ce qui a échoué, depuis où cela a été vérifié, quand cela a commencé et ce que le moniteur attendait. « La page d’accueil a renvoyé 500 sur deux vérifications consécutives » est actionnable. « Problème de site détecté » ne l’est pas.
Incluez assez de contexte pour éviter la première phase de devinettes : URL, code de statut, temps de réponse, échec TLS ou DNS, et lien vers l’historique d’incident. Pendant une panne, la clarté compte plus que la formule.
Comment réduire les faux positifs
Utilisez les échecs consécutifs, les points de sonde et des seuils de temps de réponse raisonnables. Ne réglez pas une alerte de temps de réponse si bas que la variance normale devient un incident. Ne surveillez pas une page censée bloquer les bots, exiger une session ou varier fortement par visiteur sauf si vous avez une assertion claire sur ce que signifie « sain ».
Passez en revue les premiers incidents. Si chaque alerte est du bruit, ajustez les seuils avant que les gens apprennent à muter le canal. Si les alertes arrivent après les plaintes clients, raccourcissez l’intervalle ou envoyez l’alerte à un endroit plus visible.
Comment Holter gère les alertes de panne
Holter surveille les URL, TLS, DNS, l’expiration du domaine et les check-ins heartbeat depuis l’extérieur de votre infrastructure. Vous choisissez le canal d’alerte et le seuil d’échec, afin qu’un vrai incident ne s’ouvre qu’une fois que le moniteur a assez d’éléments pour mériter votre attention.
Le plan Free couvre 5 moniteurs avec des vérifications toutes les 5 minutes et aucune carte bancaire, assez pour poser des alertes de panne fiables sur un vrai site : page d’accueil, connexion ou API, TLS, domaine et un heartbeat pour la tâche de fond que les utilisateurs ne voient jamais.
Holter surveille cela pour vous : checks externes et heartbeats pour les pannes silencieuses. Offre gratuite : 5 moniteurs, checks toutes les 5 minutes, sans carte bancaire.
Créer une alerte de panne fiable — gratuit