Le pourcentage d’uptime correspond au temps pendant lequel un service était opérationnel, divisé par la durée totale, multiplié par 100. Un mois de 30 jours compte 43 200 minutes ; avec 27 minutes d’indisponibilité, l’uptime est de (43 200 − 27) ÷ 43 200 × 100 = 99,9375 %.
La formule est simple. Obtenir un chiffre défendable l’est moins : il faut décider de la durée totale, de ce qui compte comme indisponibilité, de ce qu’on exclut et de la façon de combiner plusieurs parties d’un système. Ce guide passe chaque point en revue avec des exemples, puis explique en quoi l’uptime diffère de la disponibilité et de la fiabilité.
Pour une réponse rapide, le calculateur d’uptime convertit une durée d’indisponibilité en pourcentage, et un pourcentage en indisponibilité autorisée.
La formule de l’uptime
Uptime % = (Durée totale − Indisponibilité) ÷ Durée totale × 100
La durée totale et l’indisponibilité doivent être exprimées dans la même unité. Les minutes sont le choix pratique pour un mois, les secondes si vous avez besoin de plus de précision.
PériodeMinutesSecondesJour1 44086 400Semaine10 080604 800Mois de 30 jours43 2002 592 000Mois de 31 jours44 6402 678 400Mois moyen (30,4375 jours)43 8302 629 800Année (365,25 jours)525 96031 557 600
Utilisez la durée réelle de la période quand vous produisez un rapport contractuel, car la plupart des SLA se mesurent par mois calendaire. Le calculateur utilise le mois moyen pour que les objectifs soient comparables, c’est pourquoi il affiche 99,938 % pour ces mêmes 27 minutes.
À partir des contrôles plutôt que des minutes
Si vos données sont une liste de contrôles plutôt que des heures de panne, l’uptime est la part des contrôles réussis :
Uptime % = Contrôles réussis ÷ Total des contrôles × 100
Avec un contrôle par minute, un mois de 30 jours compte 43 200 contrôles. Si 40 ont échoué, l’uptime est de 43 160 ÷ 43 200 × 100 = 99,907 %. Cela ne fonctionne que si les contrôles tournent à intervalle fixe, et chaque contrôle échoué compte alors comme un intervalle complet d’indisponibilité. Avec des contrôles toutes les cinq minutes, une panne de 30 secondes compte soit pour cinq minutes, soit pas du tout.
Exemples chiffrés
Plusieurs incidents dans le mois
Une boutique a connu trois incidents sur un mois de 30 jours : 12 minutes le 4, 7 minutes le 15 et 24 minutes le 27. Additionnez-les d’abord : 43 minutes. Puis (43 200 − 43) ÷ 43 200 × 100 = 99,9005 %. Un mois de 30 jours à 99,9 % autorise 43 minutes et 12 secondes : la boutique a donc tenu son objectif, avec 12 secondes de marge.
Exclure la maintenance planifiée
Si votre SLA exclut la maintenance, retirez le temps de maintenance de la durée totale, et pas seulement de l’indisponibilité :
Uptime % = (Durée totale − Maintenance − Indisponibilité) ÷ (Durée totale − Maintenance) × 100
Exemple : un mois de 30 jours avec une fenêtre de maintenance de 2 heures et 30 minutes d’indisponibilité imprévue. Maintenance exclue : (43 200 − 120 − 30) ÷ (43 200 − 120) × 100 = 99,930 %. Maintenance comptée comme indisponibilité : (43 200 − 150) ÷ 43 200 × 100 = 99,653 %. Le même mois, deux chiffres très différents : c’est pourquoi le SLA doit préciser lequel s’applique.
La surveillance mise en pause fonctionne de la même façon. Si personne ne mesurait, ce temps n’est ni de l’uptime ni de l’indisponibilité, et il doit sortir de la durée totale.
Combiner l’uptime de plusieurs composants
La plupart des services dépendent de plusieurs éléments. La façon de combiner leur uptime dépend de leur montage : en chaîne ou redondant.
Composants en chaîne
Quand chaque composant doit fonctionner, multipliez leurs uptimes. Un site qui a besoin à la fois d’un serveur applicatif à 99,9 % et d’une base de données à 99,9 % peut au mieux atteindre 0,999 × 0,999 = 99,8 %, en supposant qu’ils tombent en panne à des moments différents. Ajoutez un prestataire de paiement à 99,9 % et le tunnel de paiement descend à environ 99,7 %. Chaque dépendance ajoutée abaisse le plafond.
Composants redondants
Quand l’un ou l’autre de deux composants peut faire le travail, le service n’est en panne que lorsque les deux le sont. Deux serveurs à 99 % chacun donnent en théorie 1 − (0,01 × 0,01) = 99,99 %. En pratique, ils partagent souvent un réseau, un déploiement ou une erreur de configuration, et tombent donc ensemble plus souvent que le calcul ne le suppose. Considérez le résultat comme une limite haute, pas comme une promesse.
Ne faites pas la moyenne entre moniteurs
Si la page d’accueil affiche 100 % et le tunnel de paiement 99,0 %, une moyenne de 99,5 % ne décrit rien de ce que les clients ont vécu. Présentez chaque composant séparément, et définissez à l’avance lesquels constituent « le service » dans votre SLA.
Uptime, disponibilité et fiabilité
Ces trois mots sont souvent employés comme synonymes. Ils mesurent pourtant des choses différentes, et savoir lequel vous visez rend le chiffre plus utile.
L’uptime est la part du temps pendant laquelle le service était joignable et répondait. C’est ce que calcule la formule ci-dessus, et ce que visent la plupart des SLA.
La disponibilité est la part du temps pendant laquelle le service était utilisable : joignable, correct et suffisamment rapide. Une page qui met 40 secondes à se charger est en ligne, mais pas disponible. Si vous comptez les réponses lentes ou erronées comme des échecs, vous mesurez la disponibilité.
La fiabilité est la durée pendant laquelle le service fonctionne sans défaillance, généralement mesurée par le MTBF (temps moyen entre deux pannes). Elle indique à quelle fréquence les choses cassent, pas combien de temps elles restent cassées.
Une formule classique relie la disponibilité aux deux autres chiffres :
Disponibilité = MTBF ÷ (MTBF + MTTR)
Le MTTR est le temps moyen de rétablissement. Un service qui tombe en panne en moyenne toutes les 720 heures (une fois par mois) et met une heure à se rétablir a une disponibilité de 720 ÷ 721 = 99,86 %. La formule montre aussi les deux leviers pour l’améliorer : tomber moins souvent en panne, ou se rétablir plus vite. MTTR, MTTA et MTBF expliqués détaille comment mesurer et améliorer chacun.
Deux services avec le même uptime peuvent être vécus très différemment. Une panne de 43 minutes par mois et 43 pannes d’une minute par mois donnent le même pourcentage, mais la seconde situation interrompt le travail de vos utilisateurs tous les jours. C’est pourquoi il vaut la peine de suivre le nombre d’incidents à côté du pourcentage d’uptime.
Erreurs courantes
Mesurer depuis l’intérieur. Les logs du serveur ne peuvent pas enregistrer une requête qui n’est jamais arrivée. Les problèmes DNS, les certificats expirés et les pannes réseau n’apparaissent que dans des contrôles externes.
Compter chaque micro-coupure. Un seul contrôle échoué vient souvent du réseau, pas de votre service. Confirmez les échecs par un second contrôle avant de les compter comme indisponibilité, sinon vos chiffres seront plus bas que ce que les utilisateurs ont vécu.
Arrondir au-dessus. 99,896 % n’est pas 99,9 %. Quand vous comparez à un objectif, arrondissez vers le bas, ou affichez assez de décimales pour les distinguer.
Contrôler trop rarement. L’intervalle de contrôle fixe la résolution. Un contrôle toutes les 5 ou 10 minutes ne permet pas de savoir si vous avez tenu un mois à 99,95 %, qui autorise 22 minutes.
Ne contrôler que la page d’accueil. Une page d’accueil en cache peut rester en ligne pendant que la connexion ou le paiement échouent. Surveillez les parcours dont vos utilisateurs dépendent.
Obtenir les chiffres sans tableur
Uptimecheck calcule l’uptime comme le décrit ce guide. La surveillance de disponibilité effectue des contrôles jusqu’à chaque minute depuis Stockholm, Londres et New York, et confirme chaque contrôle échoué depuis un second site. L’uptime est la part de la période sans panne confirmée ; les fenêtres de maintenance et le temps en pause ne sont pas comptés contre lui.
Les rapports affichent l’uptime, l’indisponibilité et les incidents par moniteur pour le mois en cours, le mois dernier ou les 7, 30 ou 90 derniers jours, face à un objectif de SLA de 99 % à 99,99 %, avec un export CSV. Voir comment générer des rapports face à un objectif de SLA.
Les rapports clients envoient les mêmes chiffres aux personnes pour qui vous travaillez. Voir les rapports clients.
Les pages de statut montrent à vos clients 90 jours d’historique d’uptime par composant. Voir les pages de statut.
Pour savoir ce qu’un objectif autorise avant de vous engager, lisez ce que signifie 99,9 % d’uptime ou essayez le calculateur de SLA et d’uptime.
Arrêtez de calculer l’uptime à la main. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.