Cause probable
Comment PostShip met les signaux côte à côte autour d'une panne et en tire des hypothèses classées.
Mis à jour le 11 septembre 2026
Sur cette page
Quand une URL tombe, PostShip sait au même moment beaucoup d'autres choses : un déploiement vient de partir, Vercel est en incident, le DNS a changé, les autres pages sont tombées aussi. La cause probable met ces signaux sur une ligne de temps et en tire des hypothèses, classées. C'est de la corrélation temporelle, rien de plus : un déploiement trois minutes avant un 503 est un suspect, pas un coupable. Les phrases disent « probable », jamais « certain », et disent pourquoi.
Ce que PostShip regarde
La fenêtre est de 2 heures avant le début de l'incident et 30 minutes après sa fin (ou après son début, tant qu'il n'est pas résolu, pour que la page ne change pas à chaque lecture). Les signaux lus, chacun daté :
| Signal | D'où il vient |
|---|---|
| Déploiement | Les déploiements de production de la fenêtre, avec SHA et hébergeur, et s'ils sont partis pendant un gel |
| Fournisseur | L'état courant des fournisseurs du site, si l'incident est en cours ou fini depuis moins de 3 h |
| DNS | Deux relevés qui diffèrent dans les 24 h avant, voir Domaine et DNS |
| Certificat | Un avertissement des certificats dans les 24 h avant : renouvelé, émetteur inattendu, révoqué |
| Régions | La dernière sonde multi-régions de l'URL autour du début : ok, locale, globale |
| Script tiers | Un script tiers modifié chez son hébergeur dans la fenêtre |
| Anomalie | Une anomalie de latence sur n'importe quelle URL du projet dans l'heure avant |
| Autres cibles | Le dernier passage de chaque autre URL dans les dix minutes autour du début : combien étaient en échec |
| Maintenance | Une fenêtre de maintenance déclarée couvrant le début |
| Retour au vert, prise en charge, escalade | Toujours gardés, même hors fenêtre |
Une lecture qui échoue ne fait pas tomber les autres : un signal manquant vaut mieux qu'une page vide.
Les règles de score
Les scores s'additionnent par cause, jamais entre causes. Sous 25, l'hypothèse est du bruit et n'est pas montrée. À partir de 35, confiance moyenne ; à partir de 60, confiance forte. Si tout est sous le seuil, une seule hypothèse « Cause inconnue » est rendue, avec la même clarté : « Aucun signal ne précède la panne : ni déploiement, ni changement DNS, ni fournisseur en incident. Regardez les journaux du serveur autour de 14:03. »
| Cause | Points |
|---|---|
| Maintenance annoncée | Une fenêtre déclarée couvre le début : +70. La seule cause qu'on peut presque affirmer |
| Déploiement | Le dernier déploiement avant la panne : +60 s'il date de moins de 30 min, +30 s'il date de moins de 2 h. Pendant un gel : +10. Erreur 5xx ou délai dépassé : +10. Toutes les autres URL tombées avec elle : +10. Aucune autre URL en échec alors qu'il y en a au moins deux : −10 |
| Fournisseur en incident | Incident majeur ou critique : +50 ; mineur : +25 ; en maintenance : +20 (sous le seuil seul, visible dans la chronologie). Plusieurs fournisseurs : le pire compte, chacun est cité en preuve |
| Changement DNS | Un changement dans les 2 h avant : +45. Une erreur qui parle de DNS : +30, même sans changement observé |
| Certificat | Un événement certificat avant le début : +35. Une erreur qui parle de certificat, SSL ou TLS : +40 |
| Réseau régional | Injoignable depuis certaines régions mais pas d'autres : +50. Ce n'est pas le serveur, c'est le chemin |
| Script tiers | Un script modifié dans les 2 h avant : +30 ; +15 de plus si l'erreur est un délai dépassé |
| Saturation | Une anomalie de latence dans l'heure avant, sur cette URL ou une autre : +40. Délai dépassé : +25. HTTP 502, 503 ou 504 : +15 |
| Panne du site entier | Au moins deux autres URL en échec : +30, toutes : +10 de plus. Injoignable depuis toutes les régions : +20 |
À score égal, l'ordre ci-dessus départage : le plus décisif d'abord. Chaque hypothèse retenue vient avec une phrase complète (« Un déploiement (a1b2c3d) est parti 3 min avant la panne. ») et une ligne de preuve par signal utilisé, pour que vous puissiez contester.
La chronologie
Le début, les signaux de la fenêtre, la fin, triés par date, avec leur position relative : « 3 min avant », « au moment de la panne » (à moins d'une minute près), « 12 min après ». Dans le post-mortem, les heures sont en UTC : celles des journaux de votre serveur.
Où le lire
- Projet → Incidents → « Cause probable » sur la salle d'incident : la cause probable, les autres hypothèses, la chronologie, puis la carte « Post-mortem ».
- Le post-mortem est le même contenu en Markdown : durée, impact, chronologie, cause probable et preuves, « Ce que PostShip n'a pas vu », prise en charge. Le bouton copie le texte ; la case « Partager par un lien » crée une adresse
/pm/<jeton>non listée, que vous pouvez retirer. Voir Post-mortem.
Limites et plans
Calculée pour tout incident, sur tous les plans. Sa richesse dépend de ce que le projet observe : sans webhook de déploiement, pas de signal déploiement ; sans multi-régions (Team), pas de verdict régional ; sans anomalies (Pro), pas de saturation. Voir les plans.
Dépannage
Pourquoi « Cause inconnue » alors que j'ai déployé ?
Le déploiement n'est pas dans la fenêtre de deux heures, ou il n'a pas été enregistré (webhook absent, ou déploiement de preview et non de production). La chronologie liste tout ce qui a été vu : si le déploiement n'y est pas, PostShip ne l'a pas su.
Pourquoi le déploiement est cité alors que la cause est ailleurs ?
C'est un prior : un déploiement dans la demi-heure fait +60 par construction. Lisez les preuves et les autres hypothèses ; si les autres URL répondaient, le score a déjà été baissé de 10, et la phrase le dit.