Comment surveiller la disponibilité d’un site web

Pour surveiller la disponibilité d’un site web, il faut prendre quatre décisions : quelle adresse suivre, à quelle fréquence, qui est prévenu et ce qui compte comme un échec. Ce guide les passe en revue dans l’ordre et montre à quoi chacune ressemble dans UptimeWire. Le raisonnement vaut pour n’importe quel outil de surveillance, vous pouvez donc aussi vous en servir pour juger les autres.

Si vous voulez d’abord le contexte, lisez le guide complet de la surveillance de la disponibilité d’un site web.

Ce que détecte la surveillance de la disponibilité

Un moniteur de disponibilité interroge votre adresse à intervalles réguliers et vérifie la réponse. Il détecte :

• Un serveur à l’arrêt ou qui ne répond pas.
• Un serveur qui répond par une erreur, comme 500 ou 503.
• Un domaine qui ne se résout plus.
• Une redirection qui boucle ou ne se stabilise jamais.
• Une connexion qui dépasse le délai d’attente.

Il ne détecte pas les problèmes qui laissent la réponse d’apparence saine, comme un paiement cassé derrière une page normale. Plus loin dans ce guide, vous verrez comment réduire cet écart.

Choisir l’adresse exacte à surveiller

Prenez l’adresse qu’un visiteur utiliserait réellement, écrite en entier, https:// compris.

• Utilisez l’adresse finale. Si http://example.com redirige vers https://www.example.com, surveillez la seconde. Le moniteur suit les redirections, mais l’adresse finale est celle qui compte, et cela évite une étape.
• Une adresse surveille une page. Surveiller https://example.com/ ne couvre pas https://shop.example.com/ ni https://example.com/api/. Dans UptimeWire, un site web correspond à une adresse exacte. Ajoutez séparément chaque adresse importante.
• Préférez une page qui prouve quelque chose. Une page d’accueil statique peut se charger alors que l’application derrière elle est en panne. Si vous avez une page d’état légère qui interroge la base de données, surveillez-la aussi.
• Évitez les adresses qui exigent une connexion. Un moniteur ne peut pas se connecter. Une page qui répond 401 ou 403 à un inconnu est signalée comme un échec.

Comprendre les codes d’état HTTP

À chaque vérification, le moniteur lit le code d’état. L’article sur les codes d’état HTTP les explique en détail. En résumé, pour la surveillance :

UptimeWire suit les redirections, jusqu’à une limite de cinq, puis juge la réponse finale. Un code de 200 à 399 signifie disponible. Tout le reste est un échec.

Choisir un intervalle de vérification

L’intervalle est le temps entre deux vérifications. Un site en panne ne peut être repéré que par une vérification qui s’exécute pendant la panne : un intervalle plus court trouve donc les problèmes plus tôt.

UptimeWire propose ces intervalles : 1 minute, 3 minutes, 5 minutes, 15 minutes, 30 minutes, 1 heure, 6 heures, 12 heures et 1 jour. Votre offre fixe le plus court que vous pouvez choisir :

Les intervalles plus courts que ce que permet votre offre apparaissent dans le formulaire comme verrouillés, avec l’offre qui les débloque.

Comment choisir :

• Boutique, réservation ou service payant : l’intervalle le plus court que permet votre offre.
• Site d’entreprise ou documentation : 5 minutes suffisent largement.
• Un site dont vous voulez seulement savoir qu’il n’a pas disparu depuis des jours : de 30 minutes à une heure.

L’intervalle n’est pas la même chose que le délai de détection. Une vérification en échec est répétée avant de devenir un incident, comme expliqué plus bas.

Mettre en place la surveillance dans UptimeWire

Ces étapes correspondent au produit actuel. Les écrans peuvent changer : considérez les noms comme des repères.

1. Créez un compte sur app.uptimewire.com.
2. Confirmez votre adresse e-mail. Vous ne pouvez pas ajouter de site web tant que l’adresse n’est pas confirmée. La surveillance démarre ensuite.
3. Démarrez le premier site web. Une courte configuration pose trois questions, un écran à la fois, et affiche un récapitulatif de ce qui va être fait.
   1. Site web. L’adresse à suivre, et un nom.
   2. Vérifications. L’intervalle, combien de jours avant l’expiration prévenir pour le certificat et le domaine, et une règle de texte de page facultative.
   3. Alertes. L’adresse e-mail qui reçoit les alertes de ce site web.
4. Appuyez sur « Démarrer la surveillance ». Vous pouvez aussi utiliser « Démarrer maintenant », qui reprend les réglages déjà présents sur la page, ou passer la configuration et ajouter un site web plus tard. Les réglages peuvent être modifiés ensuite.
5. Suivez la première vérification. Un écran suit et affiche le premier résultat dès qu’il arrive : en cours, disponible, impossible à ouvrir ou plus lent que prévu.

Chaque site web que vous ajoutez reçoit aussi des vérifications du certificat, de l’expiration du domaine et du DNS. Elles s’exécutent selon leurs propres calendriers, indépendamment de l’intervalle que vous avez choisi.

Configurer l’e-mail d’alerte

L’e-mail d’alerte appartient au site web. C’est là que partent les messages de panne et de rétablissement, ainsi que les avertissements sur le certificat, le domaine et le DNS.

Utilisez une adresse que quelqu’un lit. Une boîte partagée que personne n’ouvre vous donne une surveillance sans que personne ne réagisse. Pour une équipe, utilisez une adresse de groupe afin que l’alerte ne dépende pas d’une seule personne.

Ajouter d’autres canaux de notification

L’e-mail est le canal par défaut. Les autres canaux sont facultatifs et se configurent une seule fois, pour tout le compte, dans les paramètres de notification de votre profil. Ils s’appliquent ensuite à chaque site web.

Les canaux que vous pouvez utiliser dépendent de votre offre. Consultez les tarifs pour la liste actuelle.

Tous les canaux ne transportent pas tous les messages :

Comment fonctionne la confirmation des incidents

Quand une vérification échoue, UptimeWire n’alerte pas tout de suite. Il répète la vérification peu après et n’ouvre un incident que si les échecs continuent. Quand un second point de vérification est disponible, il peut aussi lui demander s’il constate le même échec.

C’est voulu. Les micro-coupures, un paquet perdu en route ou un bref redémarrage provoqueraient sinon de fausses alertes, et les fausses alertes apprennent aux gens à ignorer les vraies. Quand un incident s’ouvre, vous êtes prévenu. Quand le site répond de nouveau, le rétablissement est confirmé et vous en êtes informé aussi.

Le prix à payer est du temps. L’alerte arrive après l’intervalle, les vérifications répétées et l’acheminement du message. Aucun moniteur ne peut promettre un délai de détection exact, et un guide qui le fait en promet trop.

Ajouter une règle de texte de page quand 200 ne suffit pas

Si votre site peut répondre 200 avec un mauvais contenu, ajoutez une règle de texte de page à la vérification. À l’étape « Vérifications », vous pouvez choisir de considérer comme un échec le cas où un texte donné est absent de la page, ou celui où il y apparaît.

Par exemple, un texte toujours présent sur votre page, comme une phrase du pied de page, indique que la vraie page s’est chargée. Un texte comme « Error establishing a database connection » indique que la page d’erreur s’affiche.

À savoir :

• Le texte doit correspondre exactement à ce qui figure dans le code source de la page, majuscules comprises.
• Seul le premier mégaoctet de la page finale est lu.
• Un texte manquant est traité comme n’importe quel autre échec : répété et confirmé avant que vous soyez alerté.
• Utilisez le bouton « Tester ce texte » avant d’enregistrer, pour vous assurer que la règle se comporte comme prévu.

Examiner les premiers résultats

Après la première vérification, regardez trois choses :

1. Le statut. Le site web est-il disponible ? S’il indique qu’il n’a pas pu ouvrir l’adresse, comparez-la avec ce que vous saisissez dans un navigateur.
2. Le temps de réponse. Notez le chiffre. C’est votre référence, et les variations ultérieures prennent sens par rapport à lui. Voir temps de réponse pour ce que le chiffre inclut.
3. L’état du certificat, du domaine et du DNS. Ces vérifications suivent leurs propres calendriers : leur résultat peut donc apparaître un peu après la première vérification.

Si la première vérification échoue alors que le site fonctionne dans votre navigateur, les causes habituelles sont une faute de frappe dans l’adresse, une page qui exige une connexion, un pare-feu qui bloque les requêtes automatisées ou une redirection qui boucle.

Interpréter l’historique de surveillance

Sur plusieurs jours, l’historique fait apparaître des tendances qu’une seule vérification ne montre pas :

• Des échecs isolés à la même heure de la journée renvoient à quelque chose de planifié : une sauvegarde, un déploiement, une tâche lourde.
• Un temps de réponse qui monte lentement renvoie à une base de données qui grossit, à un processus qui fuit ou à une offre trop petite.
• Les incidents longs montrent où votre rétablissement est lent, et pas seulement votre détection.
• Aucun incident pendant des semaines est un bon résultat. C’est aussi une raison de vérifier une fois que les alertes arrivent toujours.

La disponibilité est la part de la période pendant laquelle le site était accessible. Servez-vous-en comme d’une tendance pour vous-même, pas comme d’une promesse faite aux clients.

Tester vos notifications

N’attendez pas une vraie panne pour découvrir qu’une alerte atterrit dans les spams ou chez la mauvaise personne.

1. Ajoutez un site web de test avec une adresse qui n’existe pas, ou utilisez une règle de texte de page dont vous savez qu’elle échouera.
2. Attendez l’ouverture de l’incident.
3. Vérifiez que l’e-mail arrive et que les autres canaux que vous avez activés livrent aussi.
4. Vérifiez le message de rétablissement après avoir corrigé le test.
5. Supprimez le site web de test.

Regardez dans les dossiers de spam et les filtres. Si une équipe reçoit l’alerte, vérifiez que chaque personne la reçoit réellement.

Erreurs courantes de surveillance

• Ne surveiller que la page d’accueil. Le paiement, la connexion et l’API peuvent tomber alors que la page d’accueil va bien.
• Choisir la mauvaise adresse. Surveiller une adresse qui redirige, exige une connexion ou est mise en cache par un CDN peut masquer de vrais problèmes.
• Une boîte d’alertes que personne ne lit. Une surveillance que personne ne lit n’est pas une surveillance.
• Trop faire confiance au 200. Ajoutez une règle de texte, ou surveillez une adresse plus profonde.
• Croire qu’une adresse couvre un domaine. Elle ne couvre ni les sous-domaines ni les autres chemins.
• Configurer une fois et ne jamais tester. Vérifiez le circuit des alertes de temps en temps.
• Ne s’appuyer que sur un canal de messagerie. Les avertissements de certificat n’arrivent que par e-mail et par Telegram.

Liste de contrôle de la configuration

• L’adresse exacte, avec https://, se charge sans connexion.
• L’intervalle correspond au coût d’une panne et il est permis par votre offre.
• L’e-mail d’alerte est lu par une personne.
• Les canaux supplémentaires sont connectés dans le profil, si vous les voulez.
• Une règle de texte de page est définie là où un simple 200 ne suffit pas.
• Une alerte de test et son rétablissement sont bien arrivés.
• Chaque adresse importante est ajoutée comme un site web distinct.
• Les avertissements de certificat, de domaine et de DNS sont réglés au délai dont vous avez besoin.

Découvrez maintenant comment éviter l’une des pannes les plus évitables : Comment éviter l’expiration d’un certificat SSL.