Ce que fait réellement la vérification
Une vérification d’uptime basique envoie une requête HTTP à une URL que vous choisissez — souvent la page d’accueil, parfois une page de connexion ou un endpoint de santé — puis enregistre si elle a obtenu une réponse, quel code de statut est revenu et combien de temps cela a pris. Un résultat sain est généralement un code 2xx dans une fenêtre de temps acceptable, par exemple quelques secondes.
Cette seule vérification détecte déjà les pannes les plus courantes : serveur qui ne répond pas du tout, timeout, ou page d’erreur (5xx) renvoyée au lieu du site. Elle ne détecte pas tout : une page qui renvoie 200 avec du contenu cassé à l’intérieur nécessite une vérification qui inspecte aussi le corps de la réponse, pas seulement le code de statut.
Choisir un intervalle de vérification
L’intervalle est un compromis entre la vitesse à laquelle vous découvrez un problème et le volume de vérifications dont vous avez réellement besoin. Un intervalle de 5 minutes signifie que le pire cas est un délai de 5 minutes entre le début d’une vraie panne et sa détection : correct pour la plupart des sites, y compris tout ce qui est sur le plan Free de Holter, qui vérifie toutes les 5 minutes sans carte bancaire.
Des intervalles plus rapides comptent davantage quand le coût du downtime augmente : un tunnel d’achat ou une API payante qui perd de l’argent chaque minute d’arrêt profite de vérifications plus fréquentes qu’une page marketing. Faites correspondre l’intervalle au coût réel de quelques minutes d’indisponibilité non détectée, pas à ce qui semble impressionnant.
Éviter les fausses alertes
Une seule vérification échouée n’est pas une preuve de panne : cela peut tout aussi bien être un accroc réseau transitoire entre la probe et votre serveur. Alerter au premier échec entraîne les gens à ignorer les alertes, ce qui est pire que de ne pas alerter du tout.
La solution est une règle d’échecs consécutifs : ne déclencher une alerte qu’après deux ou trois vérifications échouées d’affilée, idéalement depuis plus d’une probe location, afin qu’un problème de routage sur un chemin ne soit pas confondu avec votre site hors ligne. Cela transforme le monitoring d’uptime d’une source bruyante de faux positifs en quelque chose que les gens croient et utilisent.
Ce que « disponible » devrait vraiment vouloir dire
Un code de statut seul est une définition faible de « disponible ». Un site qui renvoie 200 en 11 secondes est techniquement disponible et pratiquement cassé pour quiconque a abandonné l’attente. Un seuil de temps de réponse, vérifié séparément du statut réussi/échoué, détecte le cas lent mais techniquement vivant qu’une vérification binaire manque complètement.
Le contenu compte aussi : une réponse 200 avec une erreur de base de données imprimée sur la page, ou une page blanche là où le contenu devrait être, passe une vérification naïve de statut tout en échouant pour chaque vrai utilisateur. Vérifier le contenu attendu dans la réponse, pas seulement le code de réponse, ferme cet écart.
Pourquoi plus d’une probe location compte
Vérifier depuis un seul point de vue ne risque pas seulement un type de fausse alerte — un accroc de routage entre cette probe et votre serveur — cela manque aussi des pannes réelles mais locales : un nœud CDN en échec dans une partie du monde, ou un résolveur DNS que certains visiteurs utilisent qui renvoie une réponse périmée. Une vérification qui demande seulement « le site est-il disponible depuis cet endroit » ne peut pas distinguer une panne globale d’une panne locale.
Vérifier depuis quelques points de sonde détecte les deux problèmes à la fois : cela écarte « c’est juste ce chemin » avant de vous alerter, et cela peut révéler une panne réelle pour une part significative des visiteurs même si elle n’est pas globale. Une seule vérification saine signifie seulement que le site est disponible depuis l’endroit où vous avez regardé.
Configurer une première vérification
Commencez par l’URL qu’un vrai visiteur touche en premier, réglez l’intervalle selon le downtime non détecté que vous pouvez tolérer, ajoutez un seuil de temps de réponse et exigez au moins deux échecs consécutifs avant qu’une alerte parte. Puis vérifiez que l’alerte fonctionne vraiment : pointez la vérification vers une URL que vous savez en échec et confirmez qu’elle arrive quelque part où quelqu’un la verra, avant de lui faire confiance.
Ce que le monitoring d’uptime seul ne détecte pas
Une vérification d’uptime réussie signifie que l’URL surveillée a répondu correctement ; elle ne dit rien des pages que vous ne vérifiez pas, des tâches de fond qui s’arrêtent silencieusement ou d’un certificat qui expire la semaine prochaine. Le monitoring d’uptime est la base, pas toute l’image : associez-le à des vérifications TLS et d’expiration de domaine, et à du monitoring de type heartbeat pour tout ce qui tourne selon un calendrier plutôt que de répondre à une requête, comme les sauvegardes ou les cron jobs.
Comment Holter le fait
Les vérifications externes de Holter s’exécutent depuis plusieurs points de sonde selon le calendrier que vous choisissez, et prennent en charge un seuil de temps de réponse à côté de la vérification réussi/échoué, afin qu’un site lent soit signalé, pas seulement un site mort. Les alertes peuvent exiger des échecs consécutifs avant de partir, pour qu’un seul accroc transitoire ne réveille personne.
Le plan Free couvre 5 moniteurs avec des vérifications toutes les 5 minutes et aucune carte bancaire : assez pour poser aujourd’hui une vraie vérification d’uptime, plus TLS et expiration de domaine, sur l’URL centrale d’un site, avant de décider si vous avez besoin de plus rapide ou de plus élaboré.
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.
Configurer une vérification d’uptime — gratuit