Statut & uptime
Du check au statut
Section intitulée « Du check au statut »Chaque région exécute ses propres checks à son propre rythme et enregistre chaque résultat (succès, code HTTP, latence, erreur). Un statut est d’abord calculé par région, à partir des derniers checks de cette région seulement :
| Statut | Règle (par région) |
|---|---|
| up | Dernier check réussi et pas lent (voir degraded) |
| degraded | Dernier check réussi mais lent — au-dessus du seuil de temps de réponse du monitor sur max(2, retries + 1) checks d’affilée, ou ≥ 2 000 ms sans seuil — ou échec mais la fenêtre de retries n’est pas encore pleine, ou réponse 3xx hors des codes acceptés (une redirection mal configurée, pas une panne — sauf si le monitor est réglé sur 3xx = down) |
| down | retries + 1 échecs consécutifs depuis cette région |
| paused / stale | Mis en pause par vous / aucun résultat reçu depuis 3 × l’intervalle (problème d’agent ou de réseau, jamais compté comme une panne) |
retries se règle par monitor (défaut 1, donc deux échecs consécutifs
sont nécessaires). Le premier échec est un avertissement léger : un faux
positif dû à un paquet perdu ne vous réveillera jamais.
Monitors multi-région : la règle de majorité
Section intitulée « Monitors multi-région : la règle de majorité »Quand un monitor tourne depuis plusieurs régions, chaque région juge la cible de son côté, puis le statut du monitor est décidé par vote majoritaire :
- DOWN — plus de la moitié des régions configurées ont confirmé la panne (leur fenêtre de retries est épuisée). 2 sur 3, 3 sur 5, 2 sur 2.
- PANNE PARTIELLE (degraded) — au moins une région confirme la panne mais pas la majorité. Le service est injoignable depuis quelque part — incident réseau régional, edge CDN, géo-blocage — et vous devez le savoir, mais la majorité du monde passe encore.
- UP — aucune région ne confirme de panne. Le rétablissement n’est déclaré que lorsque toutes les régions sont de nouveau saines.
Ce que reçoivent vos canaux d’alerte pour un monitor à 3 régions :
- Première région confirmée down → 1 alerte — Panne partielle (orange), avec la région concernée.
- Deuxième région confirmée → 1 alerte — Down (rouge), avec les deux régions.
- Les régions reviennent une à une → rien pour l’instant…
- Dernière région saine → 1 alerte — Rétabli, avec la durée totale d’indisponibilité.
Si la panne redescend sous la majorité avant d’être totalement résolue, vous recevez une désescalade Panne partielle, puis Rétabli quand tout est vert. Un monitor mono-région suit simplement sa région (avertissement léger au premier échec, down après la fenêtre de retries).
Où le statut est affiché
Section intitulée « Où le statut est affiché »Le même statut agrégé est affiché à trois endroits, toujours à partir des mêmes chiffres :
- La pastille de statut dans la barre du haut, sur toutes les pages du dashboard. Verte « Tous les systèmes opérationnels · n up » ; ambre dès qu’un monitor est dégradé ; rouge et pulsante dès qu’un monitor est down. Un clic ouvre une version condensée de la carte « Statut actuel » : ligne d’activité, barre de proportion, les monitors à traiter avec un lien vers chacun, la panne en cours ou le dernier incident, les checks sur 24 h, et un raccourci pour déclarer un incident. Elle se rafraîchit en direct via le même flux temps réel que le dashboard. Sur mobile, elle devient un point (plus un compteur en cas de problème) dans l’en-tête, qui ouvre la même carte en feuille en bas d’écran.
- La carte « Statut actuel » sur l’accueil du dashboard.
- Le badge « Alertes » de la sidebar — le nombre d’alertes non acquittées (voir Historique des alertes).
Les monitors en pause et les fenêtres de maintenance ne colorent jamais la pastille ; ils n’apparaissent qu’à l’intérieur de la carte.
Comment l’uptime % est calculé
Section intitulée « Comment l’uptime % est calculé »uptime % = temps où le monitor était disponible ÷ temps mesuré (sur la période choisie)- Un chiffre par monitor, pas par région. À chaque instant, le monitor a un seul état, décidé par la règle de majorité : il est en panne seulement tant que plus de la moitié de ses régions confirment l’échec, et disponible sinon (up, ou dégradé : panne partielle, lenteur, redirection). Une région down pendant que les autres sont up est une panne partielle : vous la voyez et êtes alerté, mais l’uptime reste à 100 %.
- Disponible avant l’alerte de rétablissement. Dès que les régions en échec ne sont plus majoritaires, le monitor compte de nouveau comme disponible, même si une région est encore rouge. L’alerte Rétabli, elle, attend que toutes les régions soient revenues.
- Pondéré par le temps, pas par le nombre de checks. Chaque état dure jusqu’au check suivant, de n’importe quelle région : un monitor vérifié toutes les 30 secondes et un autre toutes les 5 minutes sont mesurés de la même façon. Un trou de plus de trois intervalles (cinq minutes au minimum), quand le monitor est en pause ou qu’aucune sonde ne répond, ne compte ni comme disponible ni comme en panne : il est écarté.
- Écartés : les maintenances planifiées (fenêtres ponctuelles et manuelles ; les récurrentes ne sont pas déduites), les résultats en état rate-limited (HTTP 429 ou quota d’un fournisseur LLM : le service a répondu, vous êtes bridé), et le temps où le monitor était en pause.
- Lent ≠ down : un check lent (au-dessus du seuil du monitor, ou de 2 s sans seuil) s’affiche dégradé mais compte comme disponible.
- L’indisponibilité (minutes) est le temps où le monitor était en panne. Des échecs simultanés depuis plusieurs régions sont une seule panne, comptée une fois. Voir l’exemple détaillé avec trois régions.
- Le même chiffre partout : page du monitor, liste des monitors, dashboard, pages de statut, rapports SLA, API, export Prometheus et budget SLO. Seule exception : le détail par région d’une page de statut, qui montre la part de checks réussis de chaque région.
- Périodes : les cartes du dashboard utilisent 24 h ; status pages, rapports et API acceptent 24 h / 7 j / 30 j / 90 j / 365 j, toujours dans la limite de la rétention de votre plan (90 / 180 / 365 / 730 jours).
Les latences (moyenne, p50/p95/p99) n’utilisent que les checks réussis ou ayant obtenu une réponse HTTP — les 5 secondes d’abandon d’un timeout ne polluent jamais votre graphique de temps de réponse.
Ce que veulent dire les couleurs
Section intitulée « Ce que veulent dire les couleurs »Les mêmes quatre paliers partout où un uptime est affiché — le badge d’un monitor, la tuile Uptime /24 h, chaque case de la grille Disponibilité et la page de statut publique :
| Uptime | Palier | Couleur | En gros, sur 30 jours |
|---|---|---|---|
| ≥ 99,5 % | Excellent | Vert | jusqu’à 3 h 39 perdues |
| 98 – 99,5 % | Bon | Vert clair | jusqu’à 14 h 30 perdues |
| 95 – 98 % | Dégradé | Ambre | jusqu’à 36 h perdues |
| < 95 % | Critique | Rouge | plus de 36 h perdues |
Une nuance sur la grille horaire : une case ne peut prendre que les valeurs que votre intervalle autorise. À 5 minutes (12 checks dans l’heure), un seul échec fait 91,7 % — la case passe directement en Critique, sans jamais passer par Bon ni Dégradé. À 1 minute un échec fait 98,3 % et à 30 secondes 99,2 %, tous deux en Bon. Le palier dit la vérité sur ce qui s’est passé dans l’heure ; c’est l’intervalle qui décide de la finesse avec laquelle il peut le dire.
Sur la grille Disponibilité, la zone verte est dessinée en dégradé plutôt qu’en deux blocs — la plus profonde à 98 %, le vert de la marque à 100 % — et sa légende montre donc le dégradé sans chiffres. Survolez une case pour lire le pourcentage exact de cette heure.