Alertes de temps de réponse

Un service peut répondre à tous les checks et rester trop lent pour ses utilisateurs. Une alerte de temps de réponse fait passer le monitor en degraded quand ses checks dépassent un seuil que vous choisissez, et envoie une alerte degraded à ses canaux.

Disponible sur tous les plans, pour les monitors HTTP, TCP, ping, DNS, gRPC, base de données, mail et Redis. Les monitors push, groupe et modèle IA n’ont pas de seuil de temps de réponse (un monitor de modèle IA a sa propre limite de temps jusqu’au premier token).

Régler le seuil

Ouvrez le monitor (Modifier, ou Ajouter un monitor pour en créer un) et allez à l’étape Alertes. Elle contient, de haut en bas :

Tentatives avant panne — combien de checks en échec d’affilée sont tolérés avant que le monitor soit down : Aucune, 1, 2, 3, 4 ou 5 (1 par défaut).
Temps de réponse — Signaler comme lent au-delà de, en millisecondes. Les temps de réponse du monitor sur les 7 derniers jours (moyenne, p95, p99) sont affichés au-dessus du champ pour vous aider à choisir. Prenez un préréglage (500 ms, 1 s, 1,5 s, 3 s), saisissez une valeur entre 50 et 60 000 ms, ou choisissez Désactivé.
Les canaux d’alerte qui reçoivent les alertes du monitor.

Les régions d’où partent les checks se choisissent à l’étape Planification, à côté de l’intervalle.

Quand l’alerte part

Le seuil est jugé par région, comme les échecs :

Un check est lent quand il réussit et prend strictement plus que le seuil.
La région passe degraded après max(2, retries + 1) checks lents d’affilée. Avec la valeur par défaut 1 tentative, c’est 2 checks ; avec 3 tentatives, 4 checks. Un check lent isolé n’alerte jamais.
Une seule région lente suffit à rendre le monitor degraded. La lenteur ne compte jamais dans la règle de majorité : un monitor lent partout est degraded, jamais down.
Le monitor revient up au premier check sous le seuil — pas de fenêtre de confirmation au retour.
Une vraie panne l’emporte toujours : un check en échec suit la règle des tentatives habituelle et fait passer le monitor down.

Le même délai entre deux alertes que pour les autres s’applique : un monitor qui entre et sort de la lenteur n’envoie pas une alerte à chaque check.

Ce que dit l’alerte

L’alerte degraded donne la cause, le temps mesuré et les régions :

Response time 2 340 ms is above the 1 500 ms threshold (Paris, Frankfurt)

L’e-mail affiche le seuil que vous avez fixé au lieu des 2 s par défaut. Un webhook reçoit l’événement monitor.degraded avec quatre champs de plus, pour qu’un récepteur puisse traiter la lenteur à part des pannes :

{
  "event": "monitor.degraded",
  "monitor": { "name": "API", "url": "https://api.example.com" },
  "region": "fr-dc3",
  "timestamp": "2026-10-17T08:12:44.000Z",
  "reason": "latency_threshold",
  "latencyMs": 2340,
  "thresholdMs": 1500,
  "slowRegions": ["fr-dc3", "de-fra"]
}

Pages de statut

Par défaut la lenteur est publique : un monitor lent apparaît degraded (orange) sur les pages de statut qui l’affichent — vos utilisateurs la ressentent, la page le dit.

Décochez Afficher la lenteur sur les pages de statut sous le seuil pour la garder en interne : le monitor apparaît alors opérationnel sur les pages publiques, tandis que le tableau de bord, les alertes et la page du monitor le montrent toujours degraded. Une panne est toujours publique, quel que soit ce réglage.

L’uptime et le SLA ne sont pas touchés

Un check lent est un check réussi. Il compte comme up dans l’uptime %, dans les rapports et dans les chiffres de SLA : le service a répondu. Les alertes de temps de réponse parlent de qualité, pas de disponibilité.

Sur la page du monitor

Le graphique des temps de réponse trace le seuil en pointillés orange : vous voyez à quelle distance vos checks en sont.

Sans seuil

Un monitor sans seuil (Désactivé) n’envoie jamais d’alerte de temps de réponse. Les listes et l’historique des checks le montrent quand même Lent (orange) quand son dernier check a pris 2 secondes ou plus, à titre indicatif seulement.

Latence anormale (Max et Enterprise)

Un seuil fixe n’attrape que ce pour quoi vous l’avez réglé. Un service qui répond d’habitude en 180 ms et passe à 600 ms a un problème, mais reste sous un seuil de 1 s. Cochez Latence anormale sous le seuil, et OKStatus surveille aussi ce cas.

Ce qu’il apprend : pour chaque région, le p95 horaire des 28 derniers jours, à la même heure du même jour de la semaine — lundi 9 h n’est pas dimanche 3 h. La plage habituelle va du 10e au 90e centile de ces valeurs. Avec trop peu de semaines, elle se rabat sur la même heure tous les jours, puis sur toutes les heures.
Apprentissage : les alertes démarrent après 7 jours d’historique. Le formulaire affiche la progression (« 3 jours sur 7 · alertes actives à partir du … »), puis la plage habituelle à cette heure une fois apprise.
Quand elle alerte : toutes les 5 minutes, le p95 des 15 dernières minutes (au moins 3 checks réussis) est comparé au haut de la plage habituelle. Il est anormal quand il dépasse 1,5 fois ce haut et de plus de 100 ms. 3 évaluations d’affilée (environ 15 minutes) envoient une alerte degraded ; 2 évaluations revenues dans la plage la referment, et le rétablissement est envoyé si rien d’autre ne garde l’incident ouvert.
Ce qu’elle dit : « p95 response time 640 ms over 15 min (Paris) is 2.3× the usual 150–280 ms at this hour ». L’e-mail s’intitule plus lent que d’habitude ; le webhook porte "reason": "latency_anomaly", latencyMs (le p95 sur 15 minutes), usualMs (low, high) et slowRegions.
Ce qu’elle ne fait pas : elle ne change ni le statut du monitor ni son uptime, et n’envoie jamais une deuxième alerte quand un incident est déjà ouvert — elle garde seulement cet incident ouvert jusqu’au retour du temps de réponse dans sa plage habituelle.

Sur la page du monitor, le graphique des temps de réponse trace la plage habituelle en bande cyan derrière la courbe de la première région.

Sous Max l’option est visible mais verrouillée, avec un lien vers les offres. Si l’organisation passe à une offre inférieure, les évaluations s’arrêtent et une anomalie ouverte est relâchée en 15 minutes au plus.

API, Terraform et MCP

Réglage	Champ API REST et MCP	Attribut Terraform
Seuil (ms, `null` = désactivé)	`latencyThresholdMs` / `latency_threshold_ms`	`latency_threshold_ms`
Afficher la lenteur sur les pages de statut	`latencyPublic` / `latency_public`	`latency_public`
Latence anormale (Max et Enterprise)	`latencyAnomaly` / `latency_anomaly`	`latency_anomaly`

Voir l’API Monitors, le provider Terraform et le connecteur MCP.