Glossaire · Indicateurs de fiabilité
Le burn rate indique à quelle vitesse un service consomme son budget d’erreur par rapport à ce que son SLO autorise. Avec un burn rate de 1, le budget dure exactement toute la fenêtre ; à 2, il est épuisé à mi-parcours.
Le burn rate compare le taux d’erreur observé à celui que le SLO autorise. Avec un SLO de 99,9 %, le taux d’erreur autorisé est de 0,1 % : 0,5 % de requêtes en échec correspond donc à un burn rate de 5, et à ce rythme un budget d’erreur sur 30 jours dure 6 jours.
Le SRE workbook de Google fonde les alertes sur ce taux. Pour un SLO de 99,9 % sur 30 jours, il recommande d’alerter l’astreinte quand 2 % du budget sont consommés en une heure (un taux de consommation de 14,4) ou 5 % en six heures (un taux de 6), et d’ouvrir un ticket quand 10 % sont consommés en trois jours (un taux de 1). Chaque alerte vérifie aussi une fenêtre courte, pour s’arrêter peu après la fin du problème.
Une panne totale consomme vite le budget, et une simple alerte « site en panne » la détecte tout aussi rapidement : face à 99,9 %, chaque minute de panne correspond à un taux de consommation de 1 000. Les alertes de taux de consommation prouvent leur utilité sur les défaillances partielles, comme 2 % de requêtes en échec pendant des heures, qui ne font jamais tomber le site mais épuisent le budget du mois.
Burn rate = taux d’erreur observé ÷ (100 % − SLO) ; temps avant épuisement du budget = fenêtre ÷ burn rate
Exemple : Face à un SLO de 99,9 %, une panne totale consomme le budget à un taux de 1 000 : 20 minutes de panne dépensent donc 46 % d’un budget de 43 minutes et 12 secondes sur 30 jours. 0,5 % de vérifications en échec correspond à un taux de 5 et épuise le budget en 6 jours.
Uptimecheck ne calcule pas de burn rate. Pour la disponibilité, ses alertes couvrent le cas rapide : avec un intervalle de 1 minute, une panne confirmée par une seconde vérification vous parvient en une ou deux minutes. Les alertes de lenteur, envoyées après trois vérifications lentes d’affilée, repèrent un service en ligne mais trop lent, et les rapports sur les 7, 30 ou 90 derniers jours montrent quelle part d’un budget est déjà consommée.
Essai gratuit de 14 jours · Puis gratuit pour 5 moniteurs · Sans carte bancaire
Guides 6 min de lecture
Comment calculer un budget d’erreur à partir d’un SLO, ce qui le consomme, comment fonctionne le burn rate et comment rédiger une politique de budget d’erreur que votre équipe respectera vraiment.
LireGuides 7 min de lecture
Les fausses alertes apprennent aux équipes à ignorer la surveillance. Comment réduire le bruit : confirmer chaque panne par une seconde vérification, fixer des délais d’expiration raisonnables, valider la bonne URL et envoyer les alertes aux personnes qui peuvent agir.
LireUn point de départ courant pour un SLO de 99,9 % sur 30 jours consiste à déclencher une astreinte à un taux de consommation de 14,4 sur une heure ou de 6 sur six heures, et à ouvrir un ticket à 1 sur trois jours. Ajustez après quelques mois d’alertes réelles.
La fenêtre longue garantit qu’assez de budget a été consommé pour compter. La fenêtre courte garantit qu’il se consomme encore, pour que l’alerte s’arrête peu après la correction du problème.
Non. Il épuise le budget exactement à la fin de la période, ce que le SLO autorise. Au-dessus de 1, le budget s’épuise trop tôt ; en dessous de 1, il en reste.
Configurez votre premier moniteur en moins d’une minute, ou explorez d’abord la démo en ligne.
Essai gratuit de 14 jours · Puis gratuit pour 5 moniteurs · Sans carte bancaire
Avec votre accord, Google Analytics et Microsoft Clarity nous montrent quelles pages sont utiles et où les visiteurs bloquent. Ils déposent des cookies pour une durée maximale de 13 mois. Sans votre accord, aucun des deux ne s’exécute. Vous pouvez changer d’avis à tout moment via Paramètres des cookies en bas de la page. Politique de confidentialité