T+2 / T+8

Un webhook qui dit « OK » à T+0 n'attrape pas le CDN ou le DNS qui cassent quelques minutes plus tard. Après chaque déploiement de production, PostShip programme donc deux re-vérifications complètes : une à T+2 minutes, une à T+8 minutes. Elles attrapent ce qui casse une fois le cache CDN et le edge stabilisés — un problème invisible à la vérification immédiate, et que le cycle n'aurait relié à aucun déploiement.

Ce que PostShip fait

Dès que la ligne du déploiement est écrite dans Déplois, deux jobs sont posés dans la même file que le cycle, avec pour seule différence leur heure d'exécution : maintenant + 2 minutes et maintenant + 8 minutes. La file est ramassée toutes les cinq minutes : chaque reprise part au premier passage qui suit son heure. Le passage qui la ramasse fait exactement ce qu'il fait d'habitude — toutes les URL du projet — avec l'indice T+2 ou T+8 à la place de « deploy Vercel 14:32 ».

Un même déploiement ne peut porter qu'une reprise de chaque sorte : un webhook rejoué n'en programme pas une troisième.

Les reprises sont programmées pour toutes les voies qui enregistrent un déploiement de production : Vercel, Netlify, Cloudflare Pages, le webhook générique et la détection par empreinte. Une preview n'en reçoit pas : rien n'est en ligne.

Ce que vous voyez

La ligne du déploiement, dans Déplois et sur la page du ship, affiche les trois passages : « T+0 OK · T+2 OK · T+8 OK ». Chaque case vaut :

Le verdict T+0 est celui de la ligne elle-même ; T+2 et T+8 sont lus sur les deux jobs. Un déploiement détecté par empreinte a un T+0 qui est le passage de cycle où l'empreinte a changé.

Ce qui déclenche une alerte

Les reprises alertent aux mêmes conditions que le cycle (règles) : un fail qui ouvre un incident, un retour au vert qui le ferme. Le message porte la mention « Depuis le dernier déploiement : … », parce qu'un indice de déploiement est passé — c'est ce qui vous dit, à 14:40, que le 500 vient du ship de 14:32 et pas d'ailleurs.

Le radar de mutation sonne aussi sur ces passages : ce sont des passages de déploiement, et un titre qui disparaît à T+8 parce qu'un cache s'est vidé est exactement ce qu'il cherche.

Une reprise ne recalcule pas le Ship Score et ne repose pas de Check GitHub : le score et le Check sont ceux de T+0. Les reprises alertent, elles ne renotent pas.

Limites et plans

Free n'a pas de webhook de déploiement ; ses déploiements ne sont connus que par l'empreinte de build, et ce sont ceux-là qui reçoivent des reprises. Voir les plans.

Dépannage

Pourquoi T+2 reste « en attente » longtemps ?

Les reprises passent par la même file que le cycle, ramassée toutes les cinq minutes : T+2 part donc entre deux et sept minutes après le déploiement, T+8 entre huit et treize. Un passage chargé les décale encore un peu ; « en attente » au-delà d'un quart d'heure signale un ralentissement de la file, pas un problème sur votre site.

Pourquoi T+8 est en échec alors que T+0 et T+2 sont OK ?

C'est précisément le cas pour lequel les reprises existent : une invalidation de cache, une bascule DNS ou un déploiement échelonné qui finit d'arriver entre deux et huit minutes après. Ouvrez l'incident : l'URL en échec et le motif y sont.

Pourquoi les reprises n'apparaissent pas sur une preview ?

Volontaire. Une preview est vérifiée une fois, sur sa propre adresse ; elle n'a ni CDN de production ni DNS à stabiliser.