Monitoring du downtime vs monitoring d’uptime
Ils reposent sur le même mécanisme — une vérification planifiée depuis l’extérieur de votre infrastructure — mais le monitoring du downtime met l’accent sur la vitesse de détection et la qualité de l’alerte. Un outil peut techniquement « surveiller l’uptime » tout en faisant mal le monitoring du downtime, s’il vérifie rarement, alerte sur du bruit ou envoie les alertes là où personne ne les lit.
La question pratique n’est pas « est-ce que cela vérifie mon site » — la plupart des outils le font. C’est « combien de temps entre le moment où mon site tombe et le moment où un humain l’apprend », et « cette alerte atteint-elle quelqu’un qui peut agir ».
Ce qui cause réellement le downtime
La plupart des pannes remontent à une poignée de causes : problème DNS, certificat TLS expiré, domaine expiré, hôte ou serveur lui-même en échec, ou mauvais déploiement qui casse quelque chose sans renvoyer une erreur propre. Chacune demande une vérification légèrement différente pour être détectée de façon fiable : un simple ping d’uptime détecte un serveur mort, mais pas un certificat qui expire dans trois semaines.
C’est pourquoi le monitoring du downtime, bien fait, est un petit ensemble de vérifications plutôt qu’une seule : uptime, expiration TLS, expiration du domaine et résolution DNS couvrent ensemble les causes responsables de la plupart des pannes réelles.
À quelle vitesse est-ce assez rapide
La réponse honnête est : plus vite que vos utilisateurs ne le remarquent et ne se plaignent. Un intervalle de 5 minutes signifie un pire cas de 5 minutes entre le début d’une panne et sa détection par une vérification : raisonnable pour la plupart des sites, et c’est l’intervalle du plan Free de Holter. Tout service orienté clients et critique pour le revenu profite d’un intervalle plus rapide et d’un délai de grâce plus court avant l’alerte.
La vitesse de détection ne compte que si l’alerte atteint quelqu’un. Un moniteur qui envoie dans un canal que personne ne regarde, ou dans une boîte filtrée vers un dossier, ajoute sa propre latence de détection, parfois plus longue que la panne elle-même.
Erreurs qui retardent la détection
Vérifier depuis un seul emplacement. Un seul point de vue ne peut pas distinguer « le site est hors ligne » de « ce chemin réseau est en panne » : vérifier depuis quelques points de sonde l’écarte avant qu’une alerte parte.
Alerter au premier échec. Cela produit tellement de faux positifs que les gens finissent par ignorer les alertes, ce qui annule le but du monitoring.
Aucun propriétaire pour l’alerte. Une alerte qui arrive dans un endroit non surveillé est fonctionnellement identique à aucune alerte : la panne sera encore découverte d’abord par un client.
Vérifier seulement la page d’accueil. Si checkout, connexion ou une route API échoue indépendamment, une vérification limitée à la page d’accueil ne le verra pas.
Le downtime qui ne touche jamais la page d’accueil
Tout downtime ne ressemble pas à un site mort. Un cron job qui s’arrête, un worker de file qui meurt silencieusement ou une sauvegarde nocturne qui échoue à mi-chemin peuvent durer des jours sans qu’aucune vérification externe n’échoue, parce que rien n’a changé sur la page d’accueil. Ces cas demandent un autre type de monitoring : un heartbeat, où la tâche elle-même envoie un check-in en cas de succès (ou signale explicitement l’échec), et où une alerte part dès qu’un check-in attendu n’arrive pas à l’heure prévue.
Un monitoring du downtime qui ne surveille que la porte d’entrée manque entièrement cette catégorie. Un site peut sembler parfaitement sain à chaque visiteur pendant qu’une sauvegarde cesse silencieusement en dessous, et le premier signe de problème peut être de découvrir, pendant une vraie urgence, qu’il n’existe aucune sauvegarde récente à restaurer.
Après l’alerte : mesurer le temps réellement écoulé
Détecter vite le downtime n’est que la moitié du travail ; l’autre moitié consiste à savoir, après coup, combien de temps un incident a réellement duré et à quelle vitesse il a été détecté. L’historique d’incident d’un moniteur répond aux deux questions : quand la première vérification échouée a eu lieu, quand l’alerte est partie et quand les choses ont récupéré. Revoir cela après un vrai incident permet d’ajuster un seuil d’échecs consécutifs ou un intervalle de vérification dans le temps, au lieu de les fixer une fois pour toujours.
Comment Holter le fait
Holter exécute des vérifications externes — uptime, TLS, DNS, expiration de domaine — depuis plusieurs points de sonde, aux côtés de moniteurs heartbeat entrants pour les crons, files et sauvegardes qui doivent envoyer un check-in plutôt que répondre à une requête. Un incident s’ouvre dès qu’une vérification échoue au-delà de votre seuil d’échecs consécutifs, ou qu’un heartbeat attendu manque, avec alerte vers les canaux configurés.
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 détection de downtime — externe et heartbeat — sur les URL centrales et tâches de fond d’un site.
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.
Détecter le downtime plus tôt — gratuit