Documentation
Comment PostShip vérifie votre site, se branche à vos outils, et alerte seulement quand ça casse. Chaque page dit ce que la fonction fait, comment la régler, ce qui déclenche une alerte, et ce que votre plan permet.
Démarrer
3Ce que PostShip fait, et votre premier projet en cinq minutes.
Vérifications
19Ce que PostShip regarde sur vos pages, à chaque passage et à chaque déploiement.
- HTTP et assetsLa vérification par défaut — la page répond, avec le bon statut, dans le délai, et ses fichiers JS et CSS existent encore.
- Contenu attenduExiger qu'un texte soit sur la page, ou qu'il n'y soit pas — comparé comme un lecteur le ferait.
- Seuil de latenceTransformer un temps de réponse trop long en échec, donc en alerte, donc en incident.
- Pack argentSurveiller d'un coup les pages qui font perdre de l'argent quand elles cassent — accueil, tarifs, connexion, checkout.
- Parcours d'argentLa chaîne qui mène au paiement, vérifiée dans l'ordre, arrêtée à la première étape cassée.
- Formulaire canaryVérifier que l'endpoint de votre formulaire de contact accepte encore un envoi, sans polluer votre CRM.
- Open GraphVérifier que la carte sociale d'une page reste montrable — titre, description, image qui se charge.
- Sitemap et SSLLe sitemap est lu et ses pages sondées ; le certificat est suivi jusqu'à son expiration, palier par palier.
- Vérification StripeVérifier que la page où Stripe renvoie vos clients après paiement répond encore.
- Contrat d'APIPostShip apprend la forme d'une réponse JSON sur trois passages, puis alerte dès qu'elle dérive.
- Battement de cœurSurveiller ce qui tourne sans page — un cron, un worker, une sauvegarde — par l'absence d'appel.
- Contrôles du siteLes treize vérifications que PostShip pose lui-même sur votre domaine, hors quota, et qui ne tournent qu'au déploiement.
- IndexabilitéGoogle peut-il encore explorer et indexer le site après ce déploiement ?
- Visibilité IALes moteurs de réponse — ChatGPT, Claude, Perplexity, les AI Overviews de Google — peuvent-ils encore lire et citer votre site ?
- Email (DNS)Le domaine du site peut-il envoyer des emails qui arrivent ? MX, SPF, DMARC et DKIM, lus dans le DNS.
- AccessibilitéLa page d'accueil est-elle utilisable sans les yeux ? Langue, textes alternatifs, libellés, liens — lus dans le HTML servi.
- Balises SEOTitre, meta description, canonical, viewport et hreflang de la page d'accueil, tels qu'un moteur les lit.
- Poids de pageCombien pèse la page d'accueil pour un visiteur — le HTML et les ressources qu'il référence, additionnés à chaque déploiement.
- RedirectionsLes trois adresses que les gens tapent — http, www., sans www. — mènent-elles au site en https ?
Déploiements
17La vérification au moment du ship : webhooks, hébergeurs, GitHub, Ship Score.
- Connecter votre hébergeurDéclencher une vérification complète dans la seconde qui suit chaque mise en ligne, et ce que ce passage produit en plus.
- Connecter VercelVérifier le site dès que Vercel a fini de déployer, en un clic ou avec un webhook collé à la main.
- Connecter NetlifyVérifier le site dès que Netlify a fini de déployer, avec une notification créée pour vous ou un webhook signé à la main.
- Connecter Cloudflare PagesVérifier le site dès que Cloudflare Pages a fini de déployer, avec la destination et la notification créées pour vous ou à la main.
- Webhook génériquePrévenir PostShip depuis n'importe quel hébergeur ou pipeline de CI avec une adresse, un secret et une ligne de curl.
- Détection sans webhookComment PostShip reconnaît un déploiement en lisant l'empreinte de build de votre page d'accueil, sans rien brancher.
- Connecter GitHubPublier le résultat de chaque déploiement vérifié sur le commit, sous la forme d'un Check Run nommé PostShip.
- Bloquer un merge sur PostShipFaire du Check PostShip une condition de fusion, choisir ce qui le fait rougir, et poser un score plancher.
- T+2 / T+8Les deux re-vérifications automatiques programmées deux et huit minutes après chaque déploiement de production, et pourquoi elles existent.
- Ship ScoreLa note sur 100 de chaque déploiement de production, catégorie par catégorie, et ce qu'elle devient.
- Diff de shipCe que ce déploiement a changé sur chaque page surveillée, comparé au déploiement précédent, et le résumé à coller dans un ticket.
- Archive du shipL'image de partage de chaque déploiement, gardée pour montrer l'avant une fois que l'URL d'origine a disparu.
- Radar de mutationÊtre prévenu quand un titre, un H1, une description ou un og:title disparaît ou devient « coming soon » juste après un déploiement.
- PreviewsVérifier chaque déploiement de preview sur sa propre adresse, avant qu'il parte en production, et décider séparément d'en être alerté.
- Budget de performanceMesurer trois pages avec PageSpeed Insights après chaque déploiement, et faire perdre des points au ship qui ralentit le site.
- Régression visuelleComparer pixel à pixel la capture de chaque page mesurée avec celle du déploiement précédent, et alerter au-delà du seuil que vous choisissez.
- Gel de déploiementDéclarer les moments où votre équipe s'interdit de déployer, et savoir quand quelqu'un le fait quand même.
Alertes & incidents
13Où et quand PostShip vous prévient, et comment il se tait quand il le faut.
- Email, Discord, Slack, TelegramQui reçoit quoi, par quel canal, et pourquoi une alerte ne part parfois pas.
- Connecter DiscordRecevoir les alertes dans un salon Discord, et interroger le projet avec /postship.
- Connecter SlackRecevoir les alertes dans un canal Slack, et interroger le projet avec /postship.
- Connecter TelegramRecevoir les alertes dans une conversation Telegram, et interroger le projet avec /status ou /check.
- RèglesConfirmation avant alerte, heures calmes, coupure du projet et silence d'une URL.
- MaintenanceUne fenêtre ponctuelle ou une règle hebdomadaire pendant laquelle rien n'alerte, annoncée sur la page de statut.
- Webhook sortantRecevoir chaque alerte en JSON signé HMAC sur votre propre endpoint, et choisir les événements.
- IncidentsComment un incident s'ouvre et se ferme tout seul, ce que la page Incidents montre, et comment le publier.
- Cause probableComment PostShip met les signaux côte à côte autour d'une panne et en tire des hypothèses classées.
- Acquittement« Je m'en occupe » : dire à l'équipe que quelqu'un est déjà sur l'incident, et rendre la main.
- EscaladeUn incident que personne n'a pris en charge au bout de N minutes est renvoyé à toute l'équipe, une fois.
- Résumé quotidienUn message chaque matin à 8 h sur vos salons : taux de la nuit, incidents ouverts, déploiements de la veille.
- FournisseursLes douze pages de statut que PostShip suit, comment il devine celles qui vous concernent, et ce que ça change dans l'alerte.
Performance & visiteurs
5Le temps de réponse, ce que vos visiteurs mesurent, et ce qui sort de l'ordinaire.
- PerformanceLe temps de réponse de chaque page dans le temps, l'avant/après déploiement, et la bande « normal ».
- Vitals réelsLCP, INP, CLS et TTFB mesurés dans le navigateur de vos vrais visiteurs, par appareil, anonymes par construction.
- Erreurs des visiteursLes erreurs JavaScript vues par vos vrais visiteurs, regroupées par signature, et l'alerte quand un déploiement en introduit une nouvelle.
- Anomalies de latenceUne alerte quand une page devient anormalement lente pour cette heure de la semaine, avec la formule exacte.
- Vu depuis cinq continentsVos pages sondées depuis l'Europe, l'Amérique du Nord, l'Amérique du Sud, l'Asie et l'Océanie, et l'alerte quand deux régions ne les voient plus.
Sécurité & intégrité
7Ce qui doit rester fermé, ce qui doit rester le même, et ce qui doit rester à vous.
- Scripts tiersComment PostShip relève l'empreinte de chaque script chargé depuis un autre domaine, et vous prévient quand il change chez son hébergeur.
- En-têtes de sécuritéLes en-têtes que PostShip attend sur votre page d'accueil, le contenu mixte, et ce qui fait échouer le contrôle.
- Cookies et consentementLes cookies que votre serveur pose sur un premier visiteur, avant tout bandeau, et ce que PostShip en dit.
- Fichiers exposésLes chemins que PostShip sonde à la racine de votre site (.env, .git, sauvegardes, phpinfo) et comment il évite le faux positif de la SPA.
- FuitesCe que votre page d'accueil laisse voir qu'elle ne devrait pas — lorem ipsum, localhost, adresse de préproduction, clé secrète — et comment PostShip le lit.
- Certificats émisLes certificats qui existent pour votre domaine, lus dans les journaux de transparence, et ce qui alerte quand un émetteur inattendu en signe un.
- Domaine et DNSLa dérive DNS relevée à chaque déploiement, l'expiration du domaine lue par RDAP, et la frise de la page Santé qui raconte ce qui a bougé.
Pages publiques
8Ce que vos clients voient : page de statut, badge, cartes de ship, rapports.
- Page de statutL'adresse publique que vos clients ouvrent quand ça ne répond plus : composants, disponibilité, incidents publiés, abonnés, RSS, bandeau.
- Votre domaine sur la page de statutPublier la page de statut sur status.votre-domaine.fr : le TXT de preuve, le CNAME, les trois états, et la couleur d'accent.
- Calendrier de maintenanceLes fenêtres de maintenance annoncées sur la page de statut, sur trente jours, et le flux .ics que vos clients glissent dans leur agenda.
- Badge et partageLe badge SVG pass/fail à coller dans un README, la page Partage, et les liens de lecture pour un client.
- Carte de shipLa page publique non listée qui répond « est-ce que le site va bien ? » avec le score du dernier déploiement, sans ouvrir le tableau de bord.
- Rapport partageableLa page non listée que vous envoyez à un client qui demande « alors, ce mois-ci ? » : disponibilité, incidents, déploiements, budget d'erreur, contrôles du site.
- Post-mortemLe post-mortem d'un incident en Markdown, prêt à coller, et le lien non listé pour le partager avec un client puis le retirer.
- Scan publicCe que la vérification gratuite de la page d'accueil de postship.fr regarde sur une URL, comment elle la note, et ses limites anti-abus.
Automatisation
7API, CI, MCP, exports : PostShip depuis vos outils.
- APIVue d'ensemble de l'API v1 : le jeton Bearer, les quatre routes, les quotas par plan, les codes d'erreur et le format des réponses.
- POST /api/v1/checkLa référence complète de la vérification à la demande : le corps, chaque champ de la réponse, les codes HTTP, et des exemples curl, JavaScript et GitHub Actions.
- GET /api/v1/projectsLa référence des trois routes de lecture : vos projets, les incidents ouverts d'un projet, et son dernier déploiement de production.
- Vérifier depuis votre CIVérifier une URL avant de fusionner ou après un build, avec un appel HTTP depuis GitHub Actions ou GitLab CI, et faire échouer l'étape sur le verdict ou le score.
- Serveur MCPDonner à un agent dans Cursor ou Claude Code l'état de vos projets et le verdict du dernier déploiement, sans lui donner les clés.
- Jetons d'APICréer, reconnaître et révoquer un jeton psk_ : l'affichage unique, le préfixe, la limite de cinq, l'empreinte SHA-256.
- ExportsLes fichiers que vous pouvez télécharger depuis un projet — incidents, journal et performance en CSV, dernier ship en JSON — et le format exact de chacun.
Compte & plans
6Plans, facturation, équipe, données.
- Plans Free / Pro / TeamLe tableau complet de ce que chaque plan permet, limite par limite, sans surprise.
- FacturationL'essai, le changement de plan, l'annulation, l'adresse de facturation et les factures — tout ce qui touche à votre abonnement Stripe.
- ÉquipeInviter des collaborateurs sur un projet, ce que chaque rôle peut faire, et ce qui reste au propriétaire.
- ProjetsCréer un projet, ce que l'URL de base impose aux URL surveillées, la pause, les étiquettes, la suppression et les quotas.
- Sécurité du compteComment on se connecte à PostShip, la double authentification, les comptes liés, le changement d'adresse et ce qu'une session protège.
- Données & rétentionCombien de temps PostShip garde chaque donnée, comment l'exporter, ce que le beacon RUM conserve de vos visiteurs, et comment supprimer un compte.