Cause probable
Ce qui a changé juste avant, dit en une phrase
Une alerte qui dit « /checkout en échec » vous laisse enquêter. Une alerte qui dit « /checkout en échec, 3 minutes après le déploiement a1b2c3d qui a retiré Stripe.js » vous laisse corriger.
« J'ai passé une heure à chercher avant de voir le commit de mon collègue. »
Le plus long, dans un incident, n'est pas de réparer : c'est de comprendre.
- sources regardées : déploiement, DNS, hébergeur, paiement
- 4
- phrase dans l'alerte
- 1
- les fichiers changés, quand c'est un déploiement
- diff
- accusation : une piste, pas un verdict
- 0
14:22. /checkout répond 503.
Un incident s'ouvre. PostShip sait déjà ce qui a bougé avant, rangé dans d'autres tables.
Les suspects, dans l'ordre du temps.
Tout ce qui a changé avant la panne : un déploiement, un certificat, un script tiers, la charge du serveur.
Chacun reçoit une note.
Un déploiement dans la demi-heure : +60. Une erreur de serveur qui plante : +10. Sous 25, une hypothèse est du bruit : elle n'est pas montrée.
Le déploiement a1b2c3d, 3 minutes avant.
70 sur 100 : confiance forte. Le suspect numéro un, pas un coupable.
Probable, jamais certain.
La phrase le dit, et donne ses preuves, une par ligne, pour que vous puissiez les contester.
Saturation du serveur
au moment de la pannesous le seuil : pas montrée · Cause probable · confiance forte
+15 temps de réponse en hausse
Déploiement a1b2c3d
3 min avantsous le seuil : pas montrée · Cause probable · confiance forte
+60 dans la demi-heure+10 erreur 503
Script tiers modifié
40 min avantsous le seuil : pas montrée · Cause probable · confiance forte
+30 chat-widget.js a changé
Certificat renouvelé
20 h avantsous le seuil : pas montrée · Cause probable · confiance forte
+35 le certificat a bougé
Cause probable : un déploiement (a1b2c3d) est parti 3 min avant. Confiance forte.
- · Déploiement a1b2c3d à 14:19, 3 min avant.
- · L'erreur relevée (HTTP 503) est celle d'un serveur qui redémarre ou plante.
14:22. /checkout répond 503.
Un incident s'ouvre. PostShip sait déjà ce qui a bougé avant, rangé dans d'autres tables.
Les suspects, dans l'ordre du temps.
Tout ce qui a changé avant la panne : un déploiement, un certificat, un script tiers, la charge du serveur.
Chacun reçoit une note.
Un déploiement dans la demi-heure : +60. Une erreur de serveur qui plante : +10. Sous 25, une hypothèse est du bruit : elle n'est pas montrée.
Le déploiement a1b2c3d, 3 minutes avant.
70 sur 100 : confiance forte. Le suspect numéro un, pas un coupable.
Probable, jamais certain.
La phrase le dit, et donne ses preuves, une par ligne, pour que vous puissiez les contester.
Cause probable : un déploiement (a1b2c3d) est parti 3 min avant. Confiance forte.
Comment ça marche
Le dernier déploiement, et ce qu'il a changé
Quand le site est branché à GitHub, PostShip connaît les fichiers touchés par le déploiement qui précède la panne.
Le DNS et le certificat
Un enregistrement A qui change, un certificat qui expire : PostShip relève les deux à chaque passage et sait dire s'ils ont bougé entre le dernier passage vert et le premier rouge.
Votre hébergeur et votre prestataire de paiement
Les pages de statut de Vercel, Netlify, Cloudflare et Stripe sont lues au moment de l'incident.
Une piste, écartée si elle ne tient pas
La cause probable est la plus proche dans le temps et la plus liée à la page cassée.
Les signaux qu'on met côte à côte
Aucun d'eux n'est une nouveauté : ils dorment déjà dans des tables séparées. Le post-mortem les pose sur une même ligne de temps, 2 heures avant la panne et 30 minutes après.
Vos déploiements
Un déploiement dans la demi-heure qui précède est le suspect numéro un ; plus loin dans les 2 heures, il reste cité mais pèse moitié moins. On ne retient que le dernier : 2 mises en ligne ne rendent pas la cause 2 fois plus probable.
L'état de vos fournisseurs
Les pages de statut de l'hébergeur, du fournisseur de paiement, du service d'authentification. Un incident majeur déclaré au même moment change complètement la lecture d'une panne — et une maintenance annoncée aussi, dans l'autre sens.
Le DNS et les certificats
Un enregistrement qui a changé, un certificat renouvelé, un émetteur inattendu. Ce sont les causes qu'on trouve en dernier quand on cherche à la main, parce qu'on ne pense pas à les regarder.
Ce qui est tombé autour
Combien des autres URLs du projet étaient en échec au même instant, et si le reste du site répondait encore. C'est ce qui sépare « le site est tombé » de « cette page est tombée », et les deux ne s'ouvrent pas de la même façon.
Une corrélation n'est pas une preuve
Le post-mortem est de la corrélation temporelle, et il est écrit pour qu'on puisse le contredire.
Les phrases disent « probable »
Jamais « certain ». Un déploiement 3 minutes avant une erreur 503 est un suspect, pas un coupable — et la phrase nomme le délai pour que vous jugiez vous-même si le lien tient.
Chaque hypothèse montre ses preuves
Une ligne par signal utilisé, avec son heure en temps universel : celle des journaux que vous allez ouvrir. Si une preuve vous paraît fausse, l'hypothèse tombe avec elle, et c'est le but.
Sous le seuil, on se tait
Une hypothèse trop faible n'est pas affichée. Il vaut mieux une chronologie sans conclusion qu'une cause inventée : quand rien ne précède la panne, le post-mortem le dit, et c'est la réponse la plus utile qu'on puisse donner.
Il ne lit pas vos journaux
PostShip voit votre site de l'extérieur. Une requête lente en base, une file saturée, une exception dans votre code : il peut en constater l'effet, il ne peut pas en nommer la cause. La chronologie vous dit où chercher, pas ce que vous trouverez.