Anomalies de latence
Une alerte quand une page devient anormalement lente pour cette heure de la semaine, avec la formule exacte.
Plan Pro et au-delàMis à jour le 11 septembre 2026
Sur cette page
Un seuil fixe sur le temps de réponse ment deux fois : il crie sur un site lent par nature, et il se tait sur un site rapide qui vient de tripler. Ce qu'on veut savoir, c'est si ce passage sort de ce que cette page fait d'habitude à ce moment : le lundi 9 h n'a rien à voir avec le dimanche 3 h. Les anomalies de latence comparent chaque passage réussi à l'habitude de la page à cette heure de la semaine, et n'alertent qu'à l'entrée dans l'anomalie.
La ligne de base
Chaque nuit, PostShip recalcule pour chaque URL de sorte HTTP, formulaire ou parcours, et pour chacune des 168 heures de la semaine (lundi 9 h, mardi 9 h…, en UTC), deux nombres sur les passages réussis des 14 derniers jours :
- la médiane du TTFB ;
- l'écart absolu médian (MAD) : la médiane des écarts à la médiane.
Médiane et MAD plutôt que moyenne et écart-type, parce qu'une ligne de base doit résister aux anomalies qu'elle sert à détecter : trois pics dans la fenêtre ne bougent pas la médiane, ils auraient doublé l'écart-type. Un créneau qui a moins de 3 passages réussis n'a pas de ligne ; un passage dont le créneau est vide se compare à l'heure d'avant, à défaut à l'heure d'après, jamais plus loin : à deux heures, on n'est plus sûr d'être dans le même régime de trafic.
Ce rythme est visible sur la page de chaque URL, « rythme de la semaine » : la grille heure par jour de la médiane, en UTC. On y lit la nuit qui dort, le lundi 9 h qui souffre, la sauvegarde de 3 h.
La formule
Pour un passage réussi de TTFB t, avec la médiane m et le MAD de son créneau :
z = (t − m) / (1,4826 × max(MAD, 20 ms))1,4826 est la constante qui fait d'un MAD un écart-type pour une loi normale : le score se lit alors comme un z classique. Le plancher de 20 ms est le bruit réseau qu'on ne sait pas distinguer d'un vrai changement : un site très stable a un MAD presque nul, et diviser par zéro rendrait n'importe quel écart infini.
Un passage est une anomalie quand il franchit les quatre gardes, chacune contre un faux positif connu :
| Garde | Valeur | Contre quoi |
|---|---|---|
| Ligne de base assez fournie | n ≥ 5 passages | Une médiane de quatre points est celle d'une poignée de passages |
| Statistiquement rare | z > 4 | Une chance sur trente mille sous une loi normale ; à z = 3, avec un passage toutes les cinq minutes, ça sonnerait chaque jour |
| Au moins deux fois plus lent | t ≥ 2 × m | Sur un site très stable, +150 ms font z = 5 : rare, mais pas « lent » |
| Assez lent en absolu | t > 300 ms | 50 ms qui passent à 150 ms, c'est trois fois plus et personne ne s'en soucie |
Un passage plus rapide que d'habitude n'est jamais une anomalie : z est négatif, et un CDN qui se réveille n'est pas une alerte. Un passage en échec non plus : le TTFB d'une page 500 n'est pas une lenteur, c'est une panne, déjà signalée.
Ce qui déclenche une alerte
À l'entrée seulement. Une page lente pendant une heure, c'est douze passages anormaux : la première alerte dit tout, les onze suivantes ne disent plus rien. PostShip regarde si le passage précédent portait déjà une anomalie et se tait tant qu'elle dure. Le retour à la normale ne fait pas d'alerte non plus : le silence est le message.
L'alerte emprunte le canal « Contenu modifié » des alertes d'URL, avec sa propre phrase, et elle passe devant une mutation de contenu du même passage parce qu'elle est plus urgente :
3× plus lent que d'habitude à cette heure (1 850 ms contre 600 ms en temps normal)Le rapport est arrondi au dixième (« 2,5× »). L'alerte suit les règles des autres : silence, heures calmes, maintenance, et la case « Le contenu a changé après un déploiement » pour l'email. Voir Email, Discord, Slack, Telegram et Règles.
Les passages qui suivent un déploiement ne sont pas évalués : un déploiement rend les pages plus lentes le temps du cache, et ce n'est pas une anomalie, c'est un déploiement.
Où le voir
- Sur la page Performance : la bande « normal » de chaque courbe (médiane ± 2 écarts robustes, plus étroite que le seuil d'alerte, exprès) et un point rouge à chaque passage consigné anormal. Voir Performance.
- Sur la page de l'URL : le rythme de la semaine.
- Dans la cause probable : une anomalie dans l'heure avant la panne vaut +40 à l'hypothèse « Saturation ».
Régler
Rien à régler : la détection est active dès que le plan le permet, sur toutes les URL HTTP, formulaire et parcours, dès que leur ligne de base existe. Pour un seuil fixe choisi par vous, voir le seuil de latence : un échec à partir d'une valeur, à chaque passage.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Rythme de la semaine et bande « normal » | Oui | Oui | Oui |
| Détection et alerte | Non | Oui | Oui |
Voir les plans.
Dépannage
Pourquoi aucune alerte alors que ma page a doublé ?
Regardez les quatre gardes : sous 300 ms, pas d'alerte ; avec un MAD large (un site qui oscille beaucoup), doubler ne fait pas z > 4. Ou bien la page était déjà lente au passage précédent : l'alerte n'est partie qu'à l'entrée.
Pourquoi la ligne de base est vide sur une URL récente ?
Elle est calculée la nuit, sur quatorze jours, avec au moins trois passages réussis par créneau horaire. Une URL ajoutée aujourd'hui aura ses premiers créneaux demain matin, et un rythme complet dans deux semaines.