Page de statut

Une page publique par projet, à l'adresse postship.fr/s/votre-adresse. Elle affiche l'état de chaque URL surveillée — nommée par son chemin, jamais par son URL entière — et la disponibilité sur la fenêtre d'historique que votre plan conserve. Aucun détail d'échec, aucune adresse email, aucun accès à votre tableau de bord.

Ce que la page montre

• Un état global, dit par le pire de ses composants : « Tous les systèmes sont opérationnels », « Fonctionnement dégradé », « Panne en cours ». Le titre est ce que la plupart des gens lisent, il doit être vrai tout seul.
• Un composant par URL surveillée — les pages, parcours, formulaires, contrats d'API, certificat, sitemap, carte sociale que vous avez ajoutés. Les contrôles du site (sécurité, accessibilité, balises, poids, fuites, scripts tiers…) n'y figurent jamais : une page de statut dit si le site répond, pas s'il est bien fait, et un en-tête HSTS manquant n'est pas une panne pour vos visiteurs. 3 états : Opérationnel, Dégradé, En panne. Une vérification en fail est en panne ; une vérification en error est dégradée — c'est PostShip qui n'a pas réussi à conclure, pas le site qui a répondu faux. Une cible jamais exécutée est opérationnelle jusqu'à preuve du contraire : « inconnu » sur une page de statut inquiète sans informer.
• La disponibilité, en pourcentage à 2 décimales, sur les seules cibles affichées, sur la fenêtre annoncée à côté du chiffre.
• Une barre par jour, pour chaque famille de composants et chaque composant : verte à partir de 99 % de passages réussis ce jour-là, ambre en dessous, rouge sous 80 %, un simple trait gris un jour sans passage. Les barres commencent à la création du projet (au moins une semaine), pas avant : un site surveillé depuis quinze jours montre quinze barres, pas soixante-quinze jours vides.
• L'historique, mois par mois, à /s/votre-adresse/history : la disponibilité de chaque composant jour par jour et les incidents publiés du mois, depuis la création du projet.
• Une maintenance annoncée, qui prime sur tout : le site est peut-être rouge, mais quelqu'un se tient derrière cette interruption. Les fenêtres à venir sur 30 jours, avec un lien « Ajouter à mon agenda (.ics) » — voir le calendrier.
• Les incidents publiés sur la fenêtre conservée, avec leur état et l'heure de rétablissement.
• « Vu depuis le monde », l'état par continent, pour un projet qui sonde depuis plusieurs régions.
• Un formulaire d'abonnement, à partir du plan Pro, et la mention « Propulsé par PostShip » tant que vous ne l'avez pas retirée.

Le nom d'un composant est le chemin de l'URL (/checkout, ou « Accueil » pour /) ; une carte sociale devient /page (carte sociale) ; une vérification qui ne porte pas sur une page (certificat, sitemap) prend le nom de son type.

Régler

Projet → Public → Statut.

1. Adresse de la page : minuscules, chiffres, traits d'union, 3 à 40 caractères, jamais un mot réservé (api, app, status, docs…). PostShip en propose une à partir du nom du projet.
2. Titre affiché (80 caractères), vide pour garder le nom du projet.
3. Publier la page. Avant, l'adresse répond « introuvable » à tout le monde — sauf à vous, par « Aperçu de la page », qui affiche un brouillon interdit aux robots. « Retirer la page » est réversible à tout moment.
4. Composants : chaque URL surveillée a un bouton Masquer / Afficher. Masquer un composant ne cesse pas de le surveiller : il disparaît de la page publique et continue de déclencher vos alertes.
5. Abonnés et la mention PostShip (Pro), Domaine et apparence — votre propre domaine et la couleur d'accent (Pro Plus) — voir Domaine de statut.

Le lien est fait pour un pied de page : c'est l'adresse qu'on ouvre quand le site ne répond plus, donc elle doit être connue avant la panne. Le bandeau intégrable (/s/votre-adresse/embed) donne un mot et une pastille dans une iframe — jamais un script chez vous.

Les incidents

Un incident naît tout seul au moment où PostShip accepte de vous écrire — à la N-ième confirmation de vos règles — et se ferme tout seul au retour au vert. Entre les deux, depuis Projet → Incidents, vous écrivez une phrase de 140 caractères et vous la publiez : la panne est réelle, la raconter reste votre décision. 3 états : On investigue, Identifié, Résolu. Le fil RSS (/s/votre-adresse/rss.xml) reprend ces incidents publiés, rien de plus. Voir Incidents.

Les abonnés

Vos clients laissent leur adresse sur la page et reçoivent un message à la publication d'un incident (« Incident en cours ») et à sa résolution (« Incident résolu »). Rien entre les deux : un abonné écrit à chaque changement d'état se désabonne avant la fin de la panne. Mettre à jour un résumé déjà publié ne prévient pas 2 fois.

Double opt-in : rien ne part tant que le lien de confirmation n'a pas été ouvert. La réponse du formulaire est la même dans tous les cas, parce que répondre « déjà abonné » ferait de la page un annuaire. 3 demandes par heure et par adresse IP. Chaque message porte un lien de désabonnement et l'en-tête List-Unsubscribe. La carte Abonnés compte les adresses confirmées.

Ce qui déclenche une alerte

Rien depuis cette page : elle reflète vos vérifications et vos incidents, avec un cache de 30 secondes.

Limites et plans

Afficher « 100 % sur 90 jours » à partir de 7 jours de données serait un chiffre inventé. Un retour en Découverte remet la mention PostShip. Voir les plans.

Dépannage

Pourquoi la page répond-elle « introuvable » ?

Elle n'est pas publiée, ou l'adresse a changé. Une adresse inconnue et une page retirée donnent la même réponse, pour ne pas confirmer qu'un projet existe derrière une adresse devinée. Passez par « Aperçu de la page » pour la voir avant publication.

Pourquoi la disponibilité ne correspond-elle pas à mon Aperçu ?

La page ne compte que les composants affichés. Une cible masquée ou désactivée ne pèse ni sur le pourcentage ni sur l'état global — sinon on lirait « 97,2 % » sous une liste de composants tous verts.

Pourquoi mes abonnés n'ont-ils rien reçu pendant la panne ?

Ils sont prévenus à la publication de l'incident, pas à son ouverture : c'est la publication qui est la décision de leur parler. Un incident non publié ne prévient personne. Et seule une adresse confirmée reçoit quelque chose.

Votre domaine sur la page de statut

Disponible avec le plan Pro Plus.

Publier la page de statut sur status.votre-domaine.fr : le TXT de preuve, le CNAME, les 3 états, et la couleur d'accent.

Par défaut, la page de statut vit sur postship.fr/s/votre-adresse. Le jour où votre site ne répond plus, c'est donc notre nom que vos clients lisent. En plan Pro Plus, la même page répond aussi sur un sous-domaine à vous — status.acme.fr — avec un certificat émis par nos soins, et votre couleur sur le titre.

Ce que PostShip fait

3 moments, dans un ordre qui n'est pas négociable : accepter un nom, prouver qu'il appartient à qui le demande, puis seulement demander le certificat à notre hébergeur. Rien n'est demandé avant la preuve : sans elle, n'importe qui pourrait faire réclamer par notre infrastructure un domaine qui ne lui appartient pas — et servir la page de quelqu'un d'autre sous son propre nom.

Un sous-domaine, jamais le domaine nu

L'adresse doit être un sous-domaine : status.acme.fr, etat.acme.fr, ce que vous voulez. Pas acme.fr : le CNAME qu'il faudrait y poser remplacerait les enregistrements de votre site lui-même, et c'est la panne la plus chère qu'on puisse provoquer chez un client. PostShip refuse un domaine nu en le disant : « Utilisez un sous-domaine (status.acme.fr), pas le domaine nu ». Il refuse aussi postship.fr, vercel.app et localhost.

Le champ ne demande que le préfixe (status) ; le domaine du projet est affiché à côté, fixe, sans www.. Retaper son propre domaine à chaque fois est le meilleur moyen de le taper de travers — et une faute de frappe ici crée un domaine qu'on ne possède pas, donc une vérification qui n'aboutira jamais. Coller le domaine entier par habitude est accepté.

Régler

Projet → Public → Statut, section Domaine et apparence. La page doit être publiée d'abord : un domaine qui pointe vers une page éteinte ne montrerait rien.

1. Saisissez le sous-domaine et enregistrez. PostShip affiche les deux enregistrements à poser chez votre hébergeur DNS.
2. Prouver que le domaine est à vous — un enregistrement TXT sur _postship.status.acme.fr, avec la valeur affichée (postship-verification=…).
3. Faire pointer le domaine — un enregistrement CNAME sur status.acme.fr, vers cname.vercel-dns.com. La propagation prend de quelques minutes à quelques heures.
4. Cliquez Vérifier le domaine. Tant que le TXT ne porte pas la bonne valeur, rien ne se passe et rien n'est demandé à notre hébergeur. Une fois la preuve lue, le certificat est demandé automatiquement : « Domaine vérifié. Le certificat est émis dans les minutes qui suivent. »

Domaine du projet déjà vérifié ? Si vous avez vérifié le domaine du projet (Réglages → Domaine), la preuve est déjà faite pour ses sous-domaines : l'étape 2 disparaît, le certificat est demandé dès l'enregistrement, et il ne reste que le CNAME à poser.

Les 3 états

L'écran distingue 3 moments et ne les confond jamais :

Revérifier relit le TXT et redemande le certificat si besoin. Retirer le domaine n'éteint pas la page : elle revient simplement à son adresse en /s/, et un lien déjà partagé continue de fonctionner.

La couleur d'accent

Même carte, même plan : une couleur hexadécimale à 6 chiffres (#2f6df6). Elle habille le titre et le bandeau intégrable. Les états — vert, orange, rouge — ne changent pas : c'est ce qui les rend lisibles d'un coup d'œil, et une page de statut qui ne serait plus lisible ne servirait plus à rien. Vide, aucune couleur.

Ce qui déclenche une alerte

Rien : ce réglage ne produit pas d'alerte. Si le TXT est absent, le bouton répond « Aucun enregistrement TXT trouvé. La propagation DNS peut prendre quelques minutes. » ; s'il existe avec une autre valeur, « Le TXT existe mais ne porte pas la valeur attendue. Vérifiez qu'elle est recopiée en entier. »

Limites et plans

Pro Plus seulement : c'est le réglage qui suppose quelqu'un capable de toucher au DNS d'une entreprise, et il engage notre infrastructure à porter un certificat pour un domaine qui n'est pas le nôtre. Voir les plans et la tarification.

Dépannage

Pourquoi « Vérifié — certificat en cours » depuis plus de 10 minutes ?

Le CNAME n'est peut-être pas encore propagé, ou pointe ailleurs que cname.vercel-dns.com : le certificat ne peut être émis que si le nom arrive chez nous. Vérifiez avec dig status.acme.fr CNAME, puis cliquez Revérifier.

Pourquoi le TXT n'est-il pas trouvé alors que je l'ai posé ?

Le nom doit être exactement _postship.status.acme.fr — chez certains hébergeurs, le champ « nom » attend _postship.status seulement, le suffixe étant ajouté. Un TXT long est parfois découpé par le DNS en segments ; PostShip les recolle, ce n'est pas la cause.

Pourquoi ma page répond-elle « introuvable » sur mon domaine ?

Deux conditions, et les deux comptent : le domaine doit être vérifié, et la page publiée. Un domaine enregistré mais non prouvé ne rend rien, même si le CNAME est en place.

Calendrier de maintenance

Les fenêtres de maintenance annoncées sur la page de statut, sur 30 jours, et le flux .ics que vos clients glissent dans leur agenda.

Un client qui prévoit une campagne veut savoir quand votre site sera en maintenance — pas venir vérifier la page chaque semaine. La page de statut annonçait une fenêtre ponctuelle dans les 24 heures ; elle ne disait rien de « tous les dimanches de 3 h à 4 h », alors que c'est précisément ce qu'il veut savoir. Le calendrier déroule les deux — la fenêtre ponctuelle et la règle récurrente — sur un horizon, et les écrit au format iCalendar.

Ce que PostShip fait

Les fenêtres viennent des réglages de maintenance du projet : une fenêtre ponctuelle (début, fin, raison) et une règle hebdomadaire (jours, heure de début, heure de fin, fuseau, raison). Le calendrier les déroule sur 30 jours, dans l'ordre, 12 occurrences au plus — un agenda de 12 dimanches suffit à comprendre la règle.

La règle hebdomadaire est déroulée jour par jour dans son fuseau : chaque jour coché donne une fenêtre qui commence ce jour-là à l'heure de début ; si l'heure de fin est avant l'heure de début, la fenêtre finit le lendemain (23 h → 2 h). Les heures locales passent par le même convertisseur que les formulaires — c'est lui qui connaît l'heure d'été. Une fenêtre commencée la veille au soir et qui court encore ce matin est incluse.

Sur la page de statut

Quand au moins une fenêtre est prévue, la page publique affiche une section Maintenances prévues avec les 5 prochaines occurrences et le lien « Ajouter à mon agenda (.ics) ». Une fenêtre en cours prime sur les composants : le titre de la page devient « Maintenance en cours », avec la raison (ou « Intervention planifiée. »), parce que quelqu'un se tient derrière cette interruption et c'est ce que le lecteur doit lire d'abord. Une fenêtre ponctuelle qui commence dans les 24 heures est annoncée en tête de page.

La section n'existe pas quand rien n'est prévu : afficher « pas de maintenance » serait une promesse que la page ne peut pas tenir.

Le flux .ics

À l'adresse postship.fr/s/votre-adresse/maintenance.ics. Google Agenda, Outlook et Apple Calendrier lisent tous un flux iCalendar : les fenêtres apparaissent dans l'agenda du client, mises à jour à chaque relecture. Chaque occurrence a un identifiant stable (l'adresse de la page et l'heure de début) : un agenda qui relit le flux met à jour l'événement au lieu de le dupliquer. Le calendrier s'appelle « Maintenances — votre titre », chaque événement « Maintenance — votre titre », avec la raison en description quand il y en a une.

Même règle que le fil RSS : rien de plus que ce que la page montre, et la même réponse (« introuvable ») pour une adresse inconnue et une page non publiée. Le flux est mis en cache 10 minutes.

Régler

Projet → Alertes → Maintenances : une fenêtre ponctuelle sur le calendrier, ou la règle hebdomadaire.

• Fenêtre de maintenance : un début, une fin, une raison. Pendant la fenêtre, les alertes se taisent et le badge affiche « maintenance » plutôt que « passing ».
• Maintenances récurrentes : un créneau par phrase, « Chaque L M M de 03:00 à 04:00 », autant de créneaux qu'il faut (dix au plus), un fuseau pour tous. « Retirer » enlève un créneau.

Rien à faire sur la page de statut elle-même : elle lit les mêmes réglages. Pour que vos clients voient le calendrier, la page doit être publiée.

Ce qui déclenche une alerte

Rien depuis le calendrier. C'est l'inverse : pendant une fenêtre annoncée, les alertes du projet sont retenues — voir Maintenance pour ce qui se tait exactement et ce qui est rattrapé après.

Limites et plans

Le calendrier et le flux .ics suivent la page de statut, sur tous les plans ; planifier les fenêtres demande Pro, comme les règles et la page Maintenances. Aucune limite propre : 30 jours d'horizon, 12 occurrences, 5 affichées sur la page.

Dépannage

Pourquoi le flux .ics est-il vide ?

Aucune fenêtre ne tombe dans les 30 prochains jours : une fenêtre ponctuelle passée n'est plus listée, et une règle récurrente sans jour coché n'existe pas. Le fichier est valide, il ne contient simplement aucun événement.

Pourquoi mon agenda affiche-t-il la fenêtre avec une heure de décalage ?

La règle est déroulée dans le fuseau choisi dans les réglages, et les heures sont écrites en UTC dans le flux, comme la norme l'exige. Vérifiez le fuseau de la règle — pas celui de votre compte — surtout autour d'un changement d'heure.

Pourquoi la page de statut ne montre-t-elle que 5 fenêtres alors que la règle est hebdomadaire ?

La page affiche les 5 prochaines pour rester courte ; le flux .ics en porte jusqu'à 12. Un client qui veut la suite s'abonne au flux.