La fréquence de vérification est le délai maximum pendant lequel une panne peut passer inaperçue. Un contrôle toutes les cinq minutes détecte une coupure au plus tard à la tentative suivante, plus le temps de confirmation. Il n’existe pas d’intervalle universel : il dépend du coût d’une heure d’arrêt sur cette URL précise, pas du site « en général ».
Le contrôle utile part de l’extérieur de l’hébergeur. Une sonde installée sur la même machine que le site peut rester verte alors que personne n’atteint le domaine. C’est le rôle d’un service comme le monitoring SiteGarde : interroger l’URL comme le ferait un visiteur.
Choisir l’intervalle selon la page
Classez les URL avant de régler le minuteur. La page d’accueil, le paiement, la connexion et le formulaire qui apporte des demandes ne supportent pas le même délai qu’un article de blog.
| URL | Intervalle courant | Ce que vous acceptez de rater |
|---|---|---|
| Accueil, paiement, connexion | 1 à 5 minutes | Quelques minutes de panne |
| Formulaire, fiche produit majeure | 5 minutes | Une courte coupure |
| Blog, pages institutionnelles | 15 minutes | Une panne brève sur un contenu secondaire |
| Certificat, DNS, expiration du domaine | Une fois par jour | Ces échéances se jouent en jours, pas en minutes |
Ces durées sont des choix d’exploitation, à ajuster. Une boutique le samedi après-midi peut resserrer le paiement à une minute, puis le relâcher la nuit si personne ne traite l’alerte. L’intervalle ne sert à rien s’il est plus court que le délai de réaction réel.
Vérifiez l’URL finale, pas seulement le domaine nu. Une home en 200 et un /paiement en 502 est une panne partielle : la home verte ne la montre pas. Le test d’URL sert à contrôler un cas précis ; la surveillance reprend ensuite le même URL à l’intervalle choisi.
Ce qu’un intervalle court ne règle pas
Contrôler cent URL chaque minute multiplie les requêtes. Un pare-feu, un plugin de sécurité ou l’hébergeur peut ralentir ou bloquer cette source, et vous mesurez alors le blocage de votre propre sonde. Le guide sur les requêtes HTTP trop nombreuses décrit ce mécanisme. Espacez les URL secondaires plutôt que de tout passer à une minute.
Le code HTTP ne dit pas qu’un formulaire enregistre encore les messages, ni que le certificat expire dans dix jours. Ces contrôles ont leur propre rythme, plus lent, et un autre critère que le statut 200.
Une page mise en cache par un CDN peut répondre 200 depuis le cache alors que l’origine est morte. Si vous ne surveillez que l’URL publique, complétez avec un contrôle qui traverse le cache, ou avec une URL qui n’est pas mise en cache, sinon l’intervalle court rassure à tort.
Confirmer, puis ajuster
Déclenchez l’alerte après deux ou trois échecs consécutifs, pas au premier timeout. Un contrôle chaque minute avec confirmation de trois essais retarde l’alerte d’environ trois minutes : c’est le prix pour ne pas traiter les accrocs d’une seule sonde.
Notez, pendant quelques semaines, les alertes qui n’étaient pas une panne. Si elles dominent, le problème n’est pas la fréquence : c’est le critère (timeout trop court, mot-clé introuvable, redirection comptée comme une erreur). Resserrez l’intervalle seulement sur les URL où une vraie panne a été vue trop tard. Élargissez-le sur celles qui n’ont jamais justifié un message.
Revoyez la liste quand le site change : nouvelle page de commande, campagne qui rend une landing critique pendant quinze jours, puis plus. La fréquence suit le risque du moment, elle ne reste pas calée sur le réglage du jour de l’installation.
Notez à côté de chaque URL l’intervalle et le nombre d’échecs exigés avant l’alerte. Sans cette note, le réglage suivant part d’une intuition, et l’intervalle se resserre à chaque frayeur jusqu’à devenir intenable. Une page qui n’a jamais justifié de message en un mois peut passer à quinze minutes. Une page dont la panne a été vue par un client avant l’alerte doit se rapprocher, pas l’ensemble du site.