Le monitoring en temps réel d’un site internet montre l’état connu à l’instant du dernier contrôle, et le rafraîchit à un intervalle que vous avez fixé. Il sert pendant l’incident : la page répond-elle à nouveau, le code est-il revenu à 200, le contenu attendu est-il reparu. Il ne conserve pas le récit du mois, et il ne remplace pas une synthèse écrite.
L’intervalle est le délai de détection
« Temps réel » ne veut pas dire que chaque requête de visiteur est observée. Un contrôle part toutes les cinq minutes, toutes les minutes, ou à un autre pas. Une panne qui commence juste après un essai réussi reste invisible jusqu’au suivant. Le délai de détection vaut donc, au pire, la durée de cet intervalle, puis le nombre d’échecs que vous exigez avant d’alerter.
Raccourcir l’intervalle réduit ce délai. Cela augmente aussi le nombre de requêtes vers le site. Sur une page en cache, l’effet est faible. Sur une URL qui exécute une recherche lourde ou un appel de paiement, un contrôle chaque minute peut lui-même charger l’origine. Réservez le pas le plus court aux URL dont une heure d’arrêt coûte une vente ou un dossier, pas au blog entier.
L’écran doit afficher l’heure du dernier essai, pas seulement un voyant. Un voyant vert sans horodatage peut dater de la veille si le planificateur s’est arrêté. Le vert n’a de sens qu’avec « contrôlé à 14 h 06 ». Si cette heure vieillit alors que personne n’a mis le contrôle en pause, la surveillance elle-même est en panne : vous ne savez plus si la page répond, vous savez seulement qu’elle répondait à un instant dépassé.
À quoi sert l’état courant
Pendant que quelqu’un corrige, l’état courant répond à des questions courtes.
- Le dernier code est-il encore 503, ou déjà 200 ?
- La redirection est-elle revenue à un seul saut ?
- La chaîne attendue est-elle de nouveau dans le HTML ?
- Le temps de réponse est-il redescendu, ou le 200 est-il lent au point d’être inutilisable ?
On ne réécrit pas l’incident sur cet écran. On décide si la correction tient. Un test d’URL manuel, lancé dans la foulée, confirme un cas douteux sans attendre le prochain passage du planificateur.
L’alerte (e-mail, webhook) est le coup de sonnette. L’écran temps réel est ce que vous ouvrez après. Si l’alerte part et que personne ne regarde l’état, le pas court n’a servi à rien. Le guide des seuils d’alerte dit quand sonner. Celui-ci dit quoi regarder une fois réveillé.
Ce que cet écran ne conserve pas
Dès que le contrôle suivant réussit, l’écran courant redevient vert. Sans mémoire, vous ne savez plus si la panne a duré quatre minutes ou quarante, ni si elle s’était déjà produite le matin. Cette mémoire est l’historique de disponibilité : chaque essai gardé, avec son code et son délai.
La synthèse mensuelle est encore autre chose. Elle s’adresse à un client ou à une direction qui ne va pas relire les essais un par un. La rédiger à partir du voyant du jour produit un mois trop beau, ou trop vague.
Gardez donc trois usages distincts. Le temps réel pour l’astreinte, sur peu d’URL, avec l’heure du dernier essai visible. L’historique pour retrouver un créneau. La synthèse pour le compte rendu. SiteGarde peut alimenter le premier usage ; il ne dispense pas d’archiver les essais ni d’écrire le mois.