Incidents

Un incident, c'est une URL en échec. Il s'ouvre sans vous, au moment où PostShip accepte de vous écrire, et se ferme sans vous, au retour au vert. Entre les deux, la seule décision humaine est de le raconter : une phrase, publiée sur la page de statut et envoyée aux abonnés. Ce n'est pas un outil d'astreinte, pas de rotation ni de SMS : c'est ce qu'une page de statut doit pouvoir afficher, et le seul geste de la chaîne qui demande quelqu'un.

Ce que PostShip fait

Ouverture

Un incident naît à la N-ième confirmation d'échec, N étant la « Confirmation avant alerte » de Règles (1 par défaut). C'est le même instant que l'alerte, et c'est voulu : il y a incident quand il y a de quoi écrire à quelqu'un. Il naît même si l'alerte elle-même est ensuite avalée par le dédoublonnage, les heures calmes ou une maintenance : une panne dont l'alerte est retenue reste une panne.

Il porte, dès l'ouverture, un résumé pré-rempli par la phrase de l'alerte : « /checkout répond 503. », « Le prix n'apparaît plus sur /pricing. » — le chemin, jamais l'URL entière, parce que ce texte peut finir sur la page de statut. Un seul incident ouvert par URL : 2 passages concurrents ne peuvent pas en créer 2.

Fermeture

Le retour au vert de l'URL passe l'incident en « Résolu » et fixe son heure de rétablissement, qu'une alerte de rétablissement parte ou non. Le résumé n'est pas réécrit : ce qu'on a dit pendant la panne reste ce qu'on a dit.

Publication

Un incident naît non publié. La panne est réelle, la décision de la raconter appartient au propriétaire. Publier envoie la phrase sur la page de statut, dans l'historique qu'elle affiche, et par email aux abonnés de la page (« Incident en cours », ou « Incident résolu » si l'incident était déjà refermé). Mettre à jour la phrase ensuite ne prévient pas les abonnés 2 fois.

La page Incidents

Projet → Incidents, de haut en bas.

• La barre de silence : « Couper 1 h / 4 h / 24 h » et « Reprendre les alertes ». Coupe toutes les alertes du projet, tous canaux confondus ; la surveillance continue.
• En cours : une carte par URL en échec — le type, la cause en une phrase, depuis quand, qui s'en occupe (ou « personne ne s'en occupe encore ») ; une page de paiement est marquée. La carte ouvre la salle d'incident.
• 30 derniers jours : incidents, rétablissement médian, le plus long, prise en charge médiane, part prise en charge — chaque chiffre comparé aux 30 jours d'avant.
• Jour par jour : une barre par jour sur la période (calme, incident, incident sur une page de paiement). Cliquer un jour liste ses incidents.
• Historique : chaque incident résolu en carte — durée, publié ou non, qui l'a pris en charge, la cause probable. Filtres : tous, en cours, résolus, publiés, pages de paiement ; période 7, 30 ou 90 jours. 20 cartes, puis « Afficher les N incidents ».

La salle d'incident

Pour chaque incident ouvert ou récent :

1. L'état : « On investigue », « Identifié », « Résolu », suivi de « · non publié » tant qu'il ne l'est pas ; « ouvert il y a 12 min », « rétabli il y a 3 min ».
2. « Je m'en occupe » ou « Pris en charge par marie il y a 12 min » : voir Acquittement.
3. « Ce que vos clients liront » : la phrase, 140 caractères au plus. Une page de statut se lit en 10 secondes sur un téléphone ; ce qui n'y tient pas est un article qu'on n'écrira jamais pendant une panne. Puis « Publier », qui devient « Mettre à jour ».
4. Une fois publié : les boutons vers les autres états (« Identifié », « Résolu », « On investigue ») et « Retirer de la page ».
5. Le lien « Cause probable » vers la chronologie et le post-mortem : voir Cause probable.

Ce qui déclenche une alerte

L'ouverture d'un incident et l'alerte d'échec sont le même événement, soumis aux mêmes règles : voir Email, Discord, Slack. Le changement d'état ou la publication n'envoient rien sur vos canaux ; la publication envoie aux abonnés de la page de statut. L'escalade, si elle est réglée, renvoie l'incident à toute l'équipe quand personne ne l'a pris en charge à temps.

Limites et plans

Voir les plans et Données et rétention.

Dépannage

Pourquoi mon incident n'apparaît pas sur la page de statut ?

Il n'est pas publié. Écrivez la phrase et cliquez sur « Publier ». La page n'affiche que les incidents publiés, et seulement sur la fenêtre d'historique de votre plan.

Pourquoi le journal montre une alerte alors que je n'ai rien reçu ?

Le journal enregistre ce qui a été envoyé par PostShip. Si l'email n'est pas arrivé, regardez vos indésirables et la case « Une URL tombe en échec » dans Compte → Notifications. Si un canal de salon manque dans la colonne des canaux, c'est que son envoi a échoué (webhook supprimé, par exemple) : reconnectez-le depuis Intégrations.

Cause probable

Comment PostShip met les signaux côte à côte autour d'une panne et en tire des hypothèses classées.

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 3 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é :

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. »

À 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 (Pro Plus), 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 2 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.

Fournisseurs

Les 12 pages de statut que PostShip suit, comment il devine celles qui vous concernent, et ce que ça change dans l'alerte.

Quand Vercel ou Cloudflare tombe, vous recevez « votre checkout répond 502 » et cherchez chez vous pendant une heure. L'information qui vous manque est publique : la page de statut du fournisseur le dit déjà. PostShip la lit et la met en face de l'alerte, « Ce n'est peut-être pas vous », et sur l'Aperçu du projet. Vous n'avez rien à déclarer : les fournisseurs se déduisent des scripts que vos pages chargent.

Ce que PostShip suit

12 fournisseurs, tous lus par la même API (Statuspage, /api/v2/status.json), dans l'ordre où ils sont montrés : les hébergeurs et le réseau d'abord, parce que c'est là qu'une panne explique un 502.

Un fournisseur dont la page de statut ne parle pas ce dialecte n'est pas dans la liste : mieux vaut ne rien dire que lire de travers. C'est le cas de Stripe, dont la page est maison. cdnjs.cloudflare.com compte comme Cloudflare, exprès : si Cloudflare tombe, le CDN tombe avec, et le site aussi.

Les états

Le vocabulaire de Statuspage : none (opérationnel), minor, major, critical, maintenance. Seuls minor, major et critical valent « en incident » : une maintenance annoncée n'excuse pas un 502, et « none » n'a rien à dire.

Comment PostShip sait quels fournisseurs sont les vôtres

Les origines tierces sont relevées sur vos pages au moment d'un déploiement de production (les 3 derniers enregistrés). Un site qui charge va.vercel-scripts.com est sur Vercel, qu'il l'ait dit ou non. Seul l'hôte est comparé, jamais l'URL entière : une origine inconnue ne correspond à rien, et mieux vaut un fournisseur en moins qu'un faux « Vercel signale un incident » sur un site qui n'y est pas.

Sans déploiement enregistré, la liste est vide, pas fausse : voir Webhooks de déploiement et Détection sans webhook.

La fraîcheur

Les 12 pages sont relues par le passage de PostShip quand la lecture la plus récente a plus de 10 minutes, 4 pages à la fois, 4 secondes par page au plus. Le cache est commun à tous les projets : Vercel n'a qu'un état, quel que soit le projet qui le regarde. Sur échec (réseau, délai, réponse non 200, JSON illisible), la ligne n'est pas touchée : l'ancien état reste, avec son ancienne date. Une page de statut qui ne répond pas ne veut pas dire « tout va bien » ; écrire « opérationnel » à sa place serait mentir avec une date fraîche.

Ce que ça change

Dans l'alerte

Quand quelque chose tombe, l'alerte lit l'état des fournisseurs du projet. Si l'un d'eux est en incident, une phrase est glissée juste sous le récapitulatif, sur tous les canaux :

• un seul : « Ce n'est peut-être pas vous : Vercel signale un incident (Elevated errors on deployments). » — la description vient de la page du fournisseur ;
• plusieurs : « Ce n'est peut-être pas vous : Vercel, Cloudflare et Supabase signalent un incident. » — les noms seulement, 3 descriptions bout à bout ne se lisent pas.

Aucun fournisseur en incident : rien n'est ajouté. Une erreur de lecture ne retient jamais l'alerte. Voir Email, Discord, Slack.

Sur l'Aperçu

Projet → Aperçu, encadré « Vos fournisseurs » : un nom par fournisseur détecté, une pastille (verte, bleue en maintenance, rouge en incident), un lien vers sa page de statut, et « vérifié il y a 4 min ». En incident, l'encadré passe en ambre et ajoute : « Une panne chez Vercel peut expliquer un échec de vos vérifications sans que rien ait changé chez vous. » Sans fournisseur détecté, l'encadré n'apparaît pas.

Dans la cause probable

Un fournisseur en incident pendant la fenêtre vaut +50 (majeur ou critique), +25 (mineur) ou +20 (maintenance) à l'hypothèse « Fournisseur en incident », avec la description en preuve. Comme il n'y a pas d'historique, ce signal n'est lu que si l'incident est en cours ou fini depuis moins de 3 heures. Voir Cause probable.

Sur la page Tiers

La page Tiers est repoussée depuis le 25 sept. 2026 (elle reviendra) ; elle montrait les fournisseurs du site — détectés au déploiement ou déclarés à la main pour ceux que la détection ne voit pas (un service appelé côté serveur) — avec leur état à l'instant, leur page de statut, et 30 jours d'incidents chez eux : chaque changement d'état de leur page est inscrit au rafraîchissement. La page liste aussi les contrats d'API que le projet surveille.

L'alerte « Tiers en incident »

Quand un fournisseur du projet passe en incident (mineur, majeur, critique) sur sa page de statut, une alerte part sur vos canaux — « Vercel est en incident — Elevated errors » — puis une autre quand il est rétabli. À la transition seulement : pas une alerte toutes les 10 minutes tant que l'incident dure. Elle se débraye dans Alertes → Règles d'alerte.

Limites et plans

L'état des fournisseurs est lu et montré sur tous les plans ; la page Tiers, les fournisseurs déclarés, l'historique et l'alerte à la transition sont Pro Plus. La détection demande des déploiements enregistrés, et les webhooks de déploiement sont compris dans tous les plans ; la détection par empreinte fonctionne partout. Voir les plans.

Dépannage

Pourquoi Vercel n'apparaît pas alors que mon site est chez Vercel ?

Vos pages ne chargent aucune des origines de la table : un site Vercel sans Analytics ni Speed Insights, servi sur son propre domaine, ne se trahit pas. La détection ne lit que ce que la page charge, jamais le DNS.

Pourquoi la note dit « incident » alors que la page du fournisseur est verte ?

Le cache a jusqu'à 10 minutes de retard, et une page de statut qui ne répondait pas garde son dernier état. Regardez « vérifié il y a … » sur l'Aperçu.

Pourquoi Stripe n'est pas suivi ?

Sa page de statut ne sert pas de JSON à jour au format Statuspage. Plutôt que lire de travers, PostShip ne dit rien. La vérification Stripe regarde votre checkout, pas leur statut.