Surveillance de la disponibilité d’un site web

La plupart des propriétaires de site web ne se demandent « mon site est-il en ligne ? » que lorsqu’un client leur dit qu’il ne l’est pas. La surveillance de la disponibilité avance ce moment. Cette page suit une panne de la première vérification échouée jusqu’au rétablissement, et montre ce que vous pouvez et ne pouvez pas apprendre en chemin.

Elle suppose que la surveillance est déjà en place. Sinon, commencez par le guide Comment surveiller la disponibilité d’un site web.

Ce que vous dit une vérification de disponibilité

Une vérification de disponibilité interroge une adresse à intervalles réguliers et examine la réponse. Elle vous dit si l’adresse a répondu, comment le serveur a réagi et combien de temps cela a pris. Elle ne vous dit pas ce qui ne va pas.

Une adresse surveillée est une URL exacte. Si vous surveillez https://shop.example.com/, c’est la seule page vérifiée. Le paiement, la page de connexion et l’API située à une autre adresse ne sont pas couverts, sauf si vous les ajoutez comme des sites web à part entière.

Un exemple de panne

Ce qui suit est un exemple inventé, pas une histoire client. Une petite boutique surveille https://shop.example.com/ toutes les 3 minutes, et les alertes vont à une boîte partagée que le propriétaire lit.

1. La première vérification échouée. Le serveur se met à répondre par une erreur. La vérification est enregistrée comme un échec.
2. La confirmation. UptimeWire n’envoie pas d’alerte sur un seul échec. Il répète la vérification peu après. Un incident ne s’ouvre que si l’échec persiste.
3. L’alerte. Le propriétaire reçoit un message indiquant que le site web est hors ligne, avec l’heure d’ouverture de l’incident.
4. L’enquête. Le propriétaire ouvre le site web, puis le panneau de l’hébergeur, et découvre que le serveur de base de données a redémarré.
5. Le rétablissement. Dès que l’adresse répond de nouveau, le rétablissement est confirmé et un second message arrive.
6. Le bilan. Quelques jours plus tard, le propriétaire ouvre l’historique, voit l’incident et sa durée, et le compare aux précédents.

Aucune de ces étapes n’est instantanée. L’alerte arrive après l’intervalle de vérification, les vérifications répétées et la remise du message. Aucun outil de surveillance ne peut promettre un délai de détection exact.

Lire l’alerte

Une alerte de panne indique qu’une adresse surveillée a cessé de répondre correctement et que la défaillance a été confirmée. Elle ne dit pas pourquoi. Ce qu’elle vous donne, c’est un point de départ :

• Quel site web. L’alerte nomme l’adresse surveillée.
• Quand cela a commencé. L’incident a une heure de début, ce qui aide à la rapprocher d’un déploiement, d’une sauvegarde ou d’un avis de l’hébergeur.
• Ce que la vérification a vu. Un statut d’erreur, un délai d’attente dépassé ou aucune réponse du tout orientent vers des endroits différents. L’article Codes d’état HTTP explique les plus courants.

Les alertes par e-mail et par Telegram sont disponibles avec toutes les offres. Les webhooks, Discord, Slack et Teams transportent aussi les messages de panne et de rétablissement, selon l’offre. Consultez Tarifs pour savoir quelle offre inclut quel canal.

Quoi vérifier en premier

UptimeWire ne diagnostique pas la cause : les premières minutes vous appartiennent. Un ordre simple qui convient à la plupart des petits sites web :

1. Ouvrez l’adresse vous-même, dans une fenêtre de navigation privée. Si elle se charge, le problème est peut-être bref ou limité à certains visiteurs.
2. Regardez le statut que renvoie votre serveur. Une erreur 5xx renvoie au serveur ou à l’application. Un délai d’attente dépassé renvoie au réseau ou à un serveur surchargé.
3. Vérifiez l’hébergeur. Cherchez un avis de statut ou un redémarrage.
4. Vérifiez ce qui a changé. Un déploiement, une mise à jour de plugin ou un changement de configuration peu avant l’incident est une cause fréquente.
5. Confirmez le rétablissement une fois que vous avez agi, et attendez le message de rétablissement.

Utiliser l’historique après le rétablissement

Quand l’incident est terminé, l’historique transforme une mauvaise heure en information :

• Début et durée. Combien de temps le site web a été indisponible, à comparer avec ce que vous attendiez.
• Régularités. Des échecs à la même heure de la journée évoquent quelque chose de planifié, comme une sauvegarde ou une tâche lourde.
• Temps de réponse autour de l’incident. Un site web qui était lent avant de tomber évoque un problème de ressources plutôt qu’une rupture soudaine.

Le nombre de jours d’historique que vous pouvez voir dépend de votre offre. Les entrées du glossaire Disponibilité et Temps d’arrêt expliquent comment ces chiffres sont comptés, et le Calculateur de disponibilité montre quel temps d’arrêt un pourcentage donné autorise.

Ce que la surveillance de la disponibilité ne couvre pas

Soyez clair sur les limites, pour qu’une boîte de réception silencieuse ne donne pas un faux sentiment de sécurité.

• Une réponse saine n’est pas un site web qui fonctionne. Une page peut répondre normalement alors que le paiement, la connexion ou un service back-end est en panne. Vous pouvez ajouter une règle qui cherche un texte donné sur la page, ce qui réduit l’écart sans le combler.
• Une adresse n’est pas tout le site web. Les autres pages, sous-domaines et API demandent leurs propres entrées.
• La détection n’est pas instantanée. L’intervalle fixe la fréquence des requêtes vers l’adresse. La confirmation et la remise ajoutent du temps.
• Il n’y a pas de test dans un navigateur. UptimeWire n’exécute pas de parcours utilisateur comme ajouter un article au panier.
• Il n’y a pas d’analyse de la cause racine. L’alerte dit ce qui a échoué et quand, pas pourquoi.

Quand cela convient

Cette approche convient à un site web dont des personnes dépendent, où l’équipe doit être au courant rapidement d’une défaillance et voir ensuite ce qui s’est passé : une boutique, une page de réservation, un site d’entreprise, un site de documentation. Elle ne remplace pas le test des fonctionnalités d’une application.