Métriques & KPIs
Vue d’ensemble
Section intitulée « Vue d’ensemble »Chaque check exécuté par un agent produit un résultat brut : succès ou échec, mesures de temps, et pour certains types de monitors des données spécifiques au protocole. Tous les KPIs du dashboard, les graphiques et les rapports PDF dérivent de ces résultats bruts. Cette page explique chaque métrique, son calcul et ce qu’il faut surveiller.
Disponibilité
Section intitulée « Disponibilité »Uptime (%)
Section intitulée « Uptime (%) »La part du temps pendant laquelle votre service était joignable sur une période. Affiché sur des fenêtres de 24h, 7j, 30j et 365j.
disponibilité = temps UP / (temps total − temps de maintenance) × 100Les fenêtres de maintenance planifiées sont exclues du dénominateur — une interruption planifiée ne compte jamais contre votre uptime ni votre SLA.
Un monitor ne passe DOWN qu’après 2 checks consécutifs en échec : un paquet perdu ou un incident réseau transitoire ne déclenche pas de fausse panne.
Objectif SLA
Section intitulée « Objectif SLA »L’objectif de disponibilité que vous choisissez par rapport (99,5 % par défaut, p. ex. 99,9 %). Les rapports comparent l’uptime mesuré à cet objectif pour chaque monitor et signalent ceux qui l’ont manqué.
| Objectif | Downtime max / 30 jours |
|---|---|
| 99 % | ~7h 18m |
| 99,5 % | ~3h 39m |
| 99,9 % | ~43m |
| 99,99 % | ~4m 20s |
Incidents & downtime
Section intitulée « Incidents & downtime »Un incident s’ouvre quand un monitor passe DOWN (après la confirmation des 2 checks) et se ferme à son rétablissement. Le downtime total d’une période est la somme des durées d’incidents, maintenance exclue.
Temps de réponse / latence (ms)
Section intitulée « Temps de réponse / latence (ms) »Temps entre l’envoi de la requête et la réception de la réponse complète, mesuré par région — un monitor vérifié depuis Paris et Francfort a une série de latence par localisation. Le dashboard affiche la dernière valeur et une moyenne 24h ; le graphique de latence trace tout l’historique par région.
Percentiles — P50, P95, P99
Section intitulée « Percentiles — P50, P95, P99 »Les moyennes masquent les pics ; les graphiques et rapports calculent donc aussi des percentiles sur la fenêtre choisie :
- P50 (médiane) — la moitié des checks ont été plus rapides. Votre expérience « typique ».
- P95 — 95 % des checks ont été plus rapides. L’expérience de vos utilisateurs les plus lents ; le chiffre SLO standard.
- P99 — 99 % des checks ont été plus rapides. Attrape les pics rares (pauses GC, cold starts, saturation).
Un service sain garde un P95 proche du P50. Un écart qui se creuse signale une latence de queue croissante — souvent le premier symptôme de saturation.
Fiabilité
Section intitulée « Fiabilité »MTTR — Mean Time To Recovery
Section intitulée « MTTR — Mean Time To Recovery »Durée moyenne d’un incident : le temps moyen pour que le service revienne une fois tombé. Plus c’est bas, mieux c’est — c’est la vitesse de résolution.
MTBF — Mean Time Between Failures
Section intitulée « MTBF — Mean Time Between Failures »Temps moyen entre le début d’un incident et le début du suivant (calculé sur les 30 derniers jours). Plus c’est haut, mieux c’est — c’est la rareté des pannes.
À lire ensemble : MTBF élevé + MTTR bas = pannes rares et courtes.
Métriques spécifiques LLM
Section intitulée « Métriques spécifiques LLM »Les monitors LLM Canary envoient un vrai prompt à votre provider et mesurent le streaming de tokens :
TTFT — Time To First Token
Section intitulée « TTFT — Time To First Token »Temps entre l’envoi du prompt et l’arrivée du premier token. C’est le délai « est-ce que ça commence à répondre ? » perçu par l’utilisateur, et généralement le premier signal de problèmes de capacité côté provider — le TTFT dérive vers le haut bien avant que les requêtes n’échouent. Un check dépassant le Max TTFT configuré est marqué dégradé même s’il finit par aboutir.
TPOT — Time Per Output Token
Section intitulée « TPOT — Time Per Output Token »Temps moyen entre tokens une fois le streaming démarré (temps de génération total ÷ tokens produits). Il détermine la vitesse à laquelle la réponse « se tape » après le premier token.
ITL — Inter-Token Latency
Section intitulée « ITL — Inter-Token Latency »La latence entre tokens consécutifs pendant le streaming. Là où le TPOT est une moyenne, l’ITL capture la variance — les à-coups et blocages en cours de génération apparaissent ici alors que le TPOT peut rester correct.
Certificats & domaines
Section intitulée « Certificats & domaines »Pour les monitors HTTPS, OKStatus suit aussi :
- Expiration du certificat SSL — jours restants avant expiration ; des alertes partent en avance et les rapports signalent tout ce qui est sous 30 jours.
- Expiration du domaine — jours restants avant la fin de l’enregistrement du domaine, mêmes seuils.
Où chaque métrique apparaît
Section intitulée « Où chaque métrique apparaît »| Métrique | Dashboard | Détail monitor | Rapports PDF |
|---|---|---|---|
| Uptime % | ✓ | ✓ (4 fenêtres) | ✓ |
| Temps de réponse/latence | ✓ | ✓ (par région) | ✓ (moyenne) |
| P50 / P95 / P99 | ✓ | ✓ (P95/P99) | |
| MTTR / MTBF | ✓ | ✓ | |
| TTFT / TPOT / ITL | ✓ (LLM) | ✓ (LLM) | |
| SSL / expiration domaine | ✓ | ✓ |