Pour réduire les fausses alertes de la surveillance de disponibilité, confirmez chaque panne par une seconde vérification avant d’alerter, fixez des délais d’expiration adaptés au comportement habituel de votre site, vérifiez un code de statut et un contenu attendus sur une URL qui reflète vraiment le service, n’envoyez les alertes de chaque moniteur qu’aux personnes qui peuvent agir, placez les travaux planifiés dans une fenêtre de maintenance en les annonçant, et passez en revue chaque mois les moniteurs les plus bruyants. La plupart des fausses alertes viennent d’une poignée de moniteurs dont l’un de ces réglages est faux : les corriger est donc généralement rapide.
Ce guide explique pourquoi les fausses alertes sont dangereuses, d’où elles viennent et ce qu’il faut changer, réglage par réglage.
Pourquoi les fausses alertes sont plus graves qu’il n’y paraît
Une fausse alerte isolée est un petit désagrément. Un flot continu, c’est la fatigue d’alerte : on coupe le son du canal, on range les e-mails dans un dossier ou on jette un œil au téléphone avant de se rendormir. La surveillance tourne toujours, mais plus personne n’écoute. La première vraie panne qui suit est découverte à l’ancienne, par un client.
Il existe aussi un coût plus discret. Chaque fausse alerte arrache quelqu’un à son travail pour vérifier un site qui va très bien. Sur un mois, cela représente des heures de concentration perdues et une équipe qui fait moins confiance à ses outils. L’objectif n’est pas d’avoir moins d’alertes pour le principe, mais des alertes qui méritent d’être lues à chaque fois.
D’où viennent les fausses alertes
Des micro-coupures réseau entre un point de vérification et votre serveur : un paquet perdu, une route lente, un bref raté DNS.
Des délais d’expiration trop serrés pour une page parfois lente mais qui fonctionne.
Une mauvaise attente : une vérification qui exige le statut 200 d’une URL qui redirige, ou qui cherche un texte modifié lors d’une refonte.
La mauvaise URL : une page soumise à une limitation de débit, à une protection anti-bots ou à une connexion, ou un serveur de préproduction éteint la nuit.
Les travaux planifiés : déploiements et maintenances qui mettent volontairement un site hors ligne.
Un mauvais routage : une alerte techniquement juste, mais envoyée à quelqu’un qui n’y peut rien. Pour cette personne, c’est du bruit.
Confirmer chaque panne par une seconde vérification
C’est la correction la plus efficace. Quand une vérification échoue, revérifiez avant toute autre chose. Un paquet perdu ou un bref raté passe la seconde vérification ; une vraie panne échoue à nouveau. Seule une panne confirmée ouvre un incident. Cela élimine la plupart des micro-coupures sans retarder les vraies alertes de plus de quelques secondes.
Les services qui vérifient depuis plusieurs emplacements peuvent effectuer la seconde vérification ailleurs, ce qui vous apprend aussi quelque chose d’utile quand les emplacements restent en désaccord plus longtemps. Si votre site échoue depuis un continent et fonctionne depuis un autre, le problème vient probablement du routage ou d’un nœud du CDN plutôt que de votre serveur. Uptimecheck vérifie depuis Stockholm, Londres et New York, et confirme chaque panne depuis un second emplacement avant d’ouvrir un incident : une micro-coupure isolée ne réveille donc personne. La page surveillance de disponibilité explique le fonctionnement. Pour les bases sur la façon dont les vérifications deviennent des alertes, voir qu’est-ce que la surveillance de disponibilité.
Fixer des délais d’expiration réalistes
Le délai d’expiration (timeout) est le temps qu’une vérification attend avant de déclarer le site en panne. Trop serré, et la variation normale devient une panne. Trop large, et un site qui met 40 secondes à répondre est considéré comme disponible.
Examinez l’historique des temps de réponse sur quelques semaines. Notez la plage normale et les réponses normales les plus lentes.
Fixez le délai d’expiration nettement au-dessus de la réponse normale la plus lente, mais en dessous du seuil où les visiteurs abandonnent.
Traitez la lenteur comme un signal à part entière. Une page passée de 300 ms à 4 secondes mérite votre attention, mais pendant les heures de bureau, pas sous forme d’alerte de panne en pleine nuit.
Si une page frôle régulièrement le délai d’expiration, le problème ne vient pas du moniteur. Il vient de la page.
Attendre le bon code de statut et le bon contenu
Beaucoup de fausses alertes viennent de vérifications qui attendent la mauvaise chose :
Les redirections. Surveiller http://northwind.shop alors que le site redirige vers https://www.northwind.shop/ ajoute un saut qui peut échouer à lui seul. Surveillez directement l’URL finale et, si vous voulez vérifier la redirection, donnez-lui son propre moniteur.
Des vérifications de contenu fragiles. Valider un slogan marketing casse au prochain changement de texte. Choisissez un élément stable qui n’apparaît que lorsque la page fonctionne, comme le nom de l’entreprise dans le pied de page, un élément de la grille de produits ou « status »: »ok » renvoyé par un point de terminaison de santé.
Trop large. Accepter n’importe quel code 2xx ou 3xx masque de vraies pannes. N’accepter que 200 d’un point de terminaison qui renvoie légitimement 204 en crée de fausses. Calquez-vous sur ce que le point de terminaison renvoie réellement.
La validation du contenu réduit à la fois les fausses alertes et les pannes manquées : une page d’erreur de proxy qui renvoie 200 fait échouer la vérification, alors qu’un changement purement cosmétique ne la déclenche pas.
Surveiller la bonne URL
Certaines URL sont par nature de mauvaises cibles de surveillance. Les pages protégées par une protection anti-bots ou un pare-feu applicatif web peuvent bloquer de temps à autre le trafic de surveillance, ce qui ressemble à une panne. Les pages soumises à une forte limitation de débit peuvent renvoyer 429 après une rafale de vérifications. Les pages protégées par une connexion renvoient une redirection vers le formulaire de connexion. Et la page d’accueil est souvent si fortement mise en cache qu’elle reste en ligne alors que tout ce qui se trouve derrière est en panne.
Un point de terminaison de santé dédié évite tout cela. Il n’est pas mis en cache, ne coûte presque rien à servir, renvoie un corps prévisible et n’échoue que lorsqu’une dépendance échoue. Voir comment créer un point de terminaison de health check. Si vous devez surveiller une page protégée, laissez passer le service de surveillance et envoyez un en-tête user agent reconnaissable pour que le trafic soit facile à identifier.
Router les alertes par moniteur
Une alerte n’est utile qu’à quelqu’un qui peut agir. Envoyer chaque moniteur à tout le monde transforme les vraies alertes en bruit pour la plupart de leurs destinataires. Routez plutôt selon l’impact et la responsabilité :
Moniteur (exemple)CanalQuiPaiement et callback de paiementNotification push et messagerie d’équipeLa personne d’astreintePoint de terminaison de santé de l’API publiqueMessagerie d’équipe et webhookÉquipe plateformeSite marketing et blogE-mailÉquipe web, heures de bureauPréproduction et outils internesCanal de discussion séparéLeur responsable
Dans Uptimecheck, vous choisissez les canaux d’alerte par moniteur. Les alertes partent par e-mail, sur Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, par webhooks et en notifications push sur votre téléphone, sur toutes les offres. Voir alertes et notifications. Avec les plannings d’astreinte, les alertes push atteignent la personne d’astreinte du moment, et l’escalade peut retenir un canal de 5 à 60 minutes et n’alerter que si personne n’a pris en charge l’incident. Les agences peuvent regrouper les moniteurs par projet client et choisir les canaux de chaque moniteur, pour que les alertes de chaque client parviennent à l’équipe qui s’en occupe.
Gérer la maintenance planifiée
Une interruption planifiée ne devrait jamais réveiller personne. Avant une migration ou un long déploiement, placez les moniteurs concernés dans une fenêtre de maintenance. Si votre outil n’en propose pas, mettez-les en pause ou déplacez leurs alertes vers un canal discret le temps de l’opération, et faites de la reprise de la surveillance une ligne de votre checklist de déploiement.
Dans Uptimecheck, les fenêtres de maintenance peuvent être ponctuelles ou récurrentes. Pendant une fenêtre, il n’y a ni alerte, ni incident, ni perte de disponibilité, et la fenêtre est affichée sur votre page de statut et peut être envoyée par e-mail aux abonnés.
Prévenez aussi vos clients. Une note sur votre page de statut avant les travaux, avec le créneau et ce qui sera touché, évite les surprises et épargne au support des tickets sur une opération que vous aviez prévue. Les déploiements qui provoquent quelques secondes d’erreurs à chaque fois sont un autre problème : corrigez-les avec des déploiements progressifs ou sans interruption (zero-downtime) plutôt qu’en ignorant les alertes.
Utiliser les avis de rétablissement
Un avis de rétablissement est l’alerte qui annonce que c’est terminé, avec la durée totale de l’interruption. Il ne réduit pas le nombre d’alertes, mais il réduit le travail que chacune provoque. Sans lui, quelqu’un doit sans cesse vérifier si une courte panne est passée. Avec lui, une micro-coupure de deux minutes la nuit se résume à une alerte et à un message de fin qui peuvent attendre le matin. Uptimecheck envoie un avis de rétablissement après chaque incident.
Passer en revue les moniteurs les plus bruyants
Une fois par mois, listez les moniteurs qui ont le plus alerté et posez pour chacun ces questions :
Chaque alerte était-elle réelle ? Sinon, quel réglage l’a provoquée : emplacement, délai d’expiration, attente ou URL ?
Quelqu’un a-t-il agi ? Si personne ne le fait jamais, changez le routage ou supprimez le moniteur.
Le site lui-même est-il instable ? De vraies pannes courtes et fréquentes ne sont pas de fausses alertes ; elles révèlent un serveur surchargé ou une dépendance fragile, et les seuils d’alerte serveur peuvent vous aider à en trouver la cause.
Le moniteur est-il encore utile ? Les sites retirés et les vieux serveurs de préproduction sont une source de bruit fréquente.
Des rapports hebdomadaires et mensuels par e-mail qui résument disponibilité et incidents accélèrent cette revue.
Checklist contre les fausses alertes
Confirmez chaque panne par une seconde vérification avant d’alerter.
Fixez les délais d’expiration à partir de l’historique réel des temps de réponse.
Surveillez les URL finales, pas les redirections, et validez un contenu stable.
Préférez les points de terminaison de santé aux pages mises en cache ou protégées.
Envoyez les alertes de chaque moniteur aux personnes qui peuvent agir.
Placez les travaux planifiés dans une fenêtre de maintenance, et annoncez-les.
Passez en revue chaque mois les moniteurs les plus bruyants.
En résumé
Les fausses alertes sont un problème de configuration, et la plupart se corrigent en un après-midi. Confirmez chaque panne par une seconde vérification, vérifiez la bonne chose sur la bonne URL, n’envoyez les alertes que là où l’on peut agir et continuez à faire le point. La récompense : une équipe qui lit chaque alerte, parce que chaque alerte compte.
Uptimecheck revérifie chaque panne avant d’alerter et vous permet de router les alertes par moniteur. Commencez un essai gratuit de 14 jours, sans carte bancaire.