La surveillance de disponibilité est un service automatisé qui vérifie votre site web, votre API ou votre serveur à intervalle fixe et vous alerte dès qu’il cesse de répondre correctement. Elle répond à une seule question, jour et nuit : les gens peuvent-ils y accéder en ce moment ? Elle enregistre aussi le temps de chaque réponse, ce qui vous donne au fil du temps un historique précis de la disponibilité et de la vitesse.
Ce guide explique comment fonctionnent les vérifications de disponibilité, comment choisir un intervalle, pourquoi les bons services confirment une panne avant d’alerter et ce que les pourcentages de disponibilité signifient en pratique.
Comment fonctionne une vérification de disponibilité
Un service de surveillance envoie une requête à votre site depuis ses propres serveurs, exactement comme le ferait un visiteur, et évalue la réponse. Selon ce que vous surveillez, la vérification peut être :
HTTP(S) : demande une URL et examine le code de statut, le temps de réponse et, si vous le souhaitez, le contenu de la réponse. C’est la vérification standard pour les sites web et les API.
Ping : envoie un écho ICMP pour savoir si un hôte est joignable sur le réseau.
Port : ouvre une connexion vers un port TCP précis, par exemple 465 pour SMTP sur TLS ou 3306 pour une base de données, pour savoir si le service est à l’écoute.
Ce sont les vérifications de disponibilité classiques. Uptimecheck ajoute des types de moniteurs pour ce qu’elles ne voient pas : tâches cron, serveurs, enregistrements DNS et domaines, services tiers comme votre prestataire de paiement, santé du site (liens cassés, contenu mixte et vitesse des pages) et parcours qui déroulent une connexion ou un paiement étape par étape.
Une vérification HTTP réussit quand la réponse arrive à temps et correspond à ce que vous attendez. Par défaut, cela signifie un code de statut de succès. Une meilleure vérification examine aussi le contenu. Une page peut renvoyer le statut 200 et afficher quand même « Erreur de connexion à la base de données ». Vérifier que la réponse contient un mot qui n’apparaît que sur une page fonctionnelle, ou qu’une API renvoie le champ attendu, permet de détecter ces cas. Avec Uptimecheck, vous pouvez définir la méthode HTTP, les en-têtes, le corps de la requête, les codes de statut attendus, un mot-clé et des vérifications JSON pour chaque moniteur de disponibilité ou moniteur d’API.
De la vérification échouée à l’alerte
Une seule requête échouée n’est pas toujours une panne. Un paquet peut se perdre entre deux réseaux, ou un serveur peut avoir un raté d’une seconde. Si chaque échec déclenchait une alerte, les gens finiraient vite par les ignorer. C’est pourquoi une vérification bien conçue procède par étapes :
Une vérification échoue, par exemple sur un timeout ou un 503.
Le service vérifie à nouveau, idéalement depuis une seconde région.
Si la panne est confirmée, un incident s’ouvre et les alertes partent.
Quand les vérifications repassent, une notification de rétablissement est envoyée avec la durée totale d’indisponibilité.
Vérifier depuis deux régions a un double intérêt. Cela filtre les fausses alertes dues à un seul chemin réseau, et cela montre quand une panne est régionale : si votre site échoue depuis l’Europe mais fonctionne depuis les États-Unis, le problème vient probablement du routage ou d’un nœud de CDN, pas de votre serveur. Uptimecheck vérifie depuis Stockholm, Londres et New York, et confirme chaque panne depuis un second emplacement avant d’ouvrir un incident : un simple accroc ne réveille donc personne.
Choisir un intervalle de vérification
L’intervalle correspond à la durée maximale pendant laquelle une panne peut passer inaperçue. Avec un intervalle de cinq minutes, une panne qui commence juste après une vérification est détectée jusqu’à cinq minutes plus tard, plus le temps de confirmation. Avec des vérifications chaque minute, elle est détectée en une minute environ.
En règle générale :
Chaque minute pour tout ce qui rapporte de l’argent ou sert des clients : boutiques, produits SaaS, systèmes de réservation, API.
Toutes les cinq minutes pour les projets personnels, les outils internes et les sites où quelques minutes de plus n’ont pas d’importance.
Uptimecheck vérifie chaque minute sur les offres payantes et toutes les 5 minutes sur l’offre Free. Consultez les tarifs pour plus de détails.
Ce que les pourcentages de disponibilité représentent en minutes
La disponibilité s’exprime généralement en pourcentage du temps. Les chiffres semblent proches, mais l’écart en indisponibilité réelle est important. Sur un an :
99 % autorise 3 jours, 15 heures et 36 minutes d’indisponibilité.
99,9 % autorise 8 heures, 45 minutes et 36 secondes.
99,99 % autorise 52 minutes et 34 secondes.
Par mois, 99,9 % représente environ 43 minutes. Cela peut être un long incident ou plusieurs courts. La surveillance vous dit lequel, et c’est important, car la solution diffère. Une longue panne pointe vers une défaillance unique. Plusieurs courtes signalent souvent un serveur surchargé ou une dépendance instable.
Que surveiller
La plupart des équipes commencent par la page d’accueil. C’est un bon début, mais la page d’accueil est souvent mise en cache et c’est la dernière à tomber. Un ensemble de moniteurs utile couvre :
Les pages qui rapportent : paiement, inscription, réservation.
La page de connexion, qui dépend de la base de données et du stockage des sessions.
Les API publiques dont dépendent vos applications et vos intégrations.
Les services annexes comme les serveurs de messagerie et les bases de données, avec des vérifications de port.
Ce qui expire : les certificats SSL et les domaines.
Les tâches planifiées, avec des heartbeats, car une sauvegarde ratée ne fait pas tomber votre site mais mérite quand même une alerte.
Où envoyer les alertes
Une alerte n’est utile que si elle atteint quelqu’un qui peut agir. L’e-mail convient à la plupart des alertes en journée. Pour les pannes de nuit, un canal qui envoie une notification sur un téléphone est plus difficile à manquer. Les messageries d’équipe comme Slack, Discord, Telegram ou Microsoft Teams tiennent tout le monde informé et donnent à l’incident un espace de discussion commun. Les webhooks vous permettent d’envoyer les alertes dans vos propres systèmes. Uptimecheck envoie des alertes par e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks et notifications push sur votre téléphone, sur toutes les offres. Consultez les notifications.
Checklist de la surveillance de disponibilité
Listez les pages, API et services qui comptent, en commençant par ceux qui rapportent de l’argent.
Ajoutez un moniteur HTTP(S) pour chacun, avec une validation du contenu sur les plus importants.
Choisissez un intervalle de 1 minute pour les vérifications critiques pour l’activité.
Vérifiez depuis plus d’une région.
Envoyez les alertes vers au moins deux canaux, dont un adapté à la nuit.
Ajoutez des moniteurs SSL, de domaine et de heartbeat pour tout ce qui peut expirer ou s’arrêter sans bruit.
Publiez une page de statut pour que vos clients voient ce qui se passe pendant un incident.
Passez en revue l’historique des incidents et les temps de réponse chaque mois.
En résumé
La surveillance de disponibilité transforme « le site est peut-être en panne » en « le site est en panne depuis deux minutes, voici l’erreur, et la bonne personne est déjà au courant ». Choisissez un intervalle court, confirmez les pannes avant d’alerter, validez le contenu autant que les codes de statut et envoyez les alertes là où elles seront vues.
Uptimecheck couvre les sites web, API, serveurs, tâches cron, DNS, SSL, domaines, services tiers, la santé du site et les parcours en plusieurs étapes dans un seul compte, à prix fixe. Essayez-le gratuitement pendant 14 jours, sans carte bancaire.