Previews
Vé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é.
Plan Pro et au-delàMis à jour le 11 septembre 2026
Sur cette page
Le webhook de production arrive après coup : le 500 est déjà en ligne. Une preview, elle, se vérifie avant. Avec la vérification des previews, chaque preview Vercel, chaque deploy-preview ou branch-deploy Netlify et chaque preview Cloudflare Pages est vérifiée sur sa propre adresse, jamais contre votre production, et le résultat est posé sur le commit de la pull request.
Régler
Sur Projet → Intégrations, carte Déploiement, sous les trois hébergeurs, deux boutons — parce que ce sont deux décisions :
- Activer la vérification des previews. Les checks tournent contre l'URL de preview. Le résultat est visible dans Déplois (badge « Preview ») et sur le Check GitHub du commit.
- Alerter sur les previews, visible seulement une fois la première activée. Désactivé par défaut : six pull requests dans l'après-midi feraient six messages pour des pages qui ne sont pas en ligne, et c'est ce bruit-là qui fait couper les alertes — production comprise.
Le webhook de l'hébergeur doit être branché (Connecter votre hébergeur) : c'est lui qui annonce la preview et son adresse.
Ce que PostShip vérifie
Chaque URL surveillée est réécrite sur l'hôte de la preview — https://www.acme.fr/tarifs devient https://acme-git-feature-x.vercel.app/tarifs — puis vérifiée comme d'habitude :
| Sorte d'URL | Sur une preview |
|---|---|
| HTTP & assets, avec les assertions du pack argent et l'en-tête privé de la cible | Oui |
| Open Graph | Oui |
| Sitemap | Oui |
| Formulaire canary | Oui — une route qui a bougé casse sur la preview d'abord, c'est tout l'intérêt |
| Parcours d'argent | Oui, chaque marche réécrite sur l'hôte de preview |
| Certificat SSL | Non : c'est celui de l'hébergeur, renouvelé par lui |
| Indexabilité | Non : une preview est noindex par construction |
| Vérification Stripe | Non : l'URL de succès d'un vrai paiement ne pointe pas sur une preview |
Puis, après les vérifications, la mesure PageSpeed et la comparaison visuelle de la preview contre la dernière capture de production — ce que la pull request va changer, avant qu'elle parte. Sans budget, sans note et sans alerte : rien n'est en ligne.
Comment PostShip reconnaît une preview dépend de l'hébergeur : target différent de production chez Vercel, context en deploy-preview ou branch-deploy chez Netlify, environment à preview ou un sous-domaine <label>.<projet>.pages.dev chez Cloudflare. L'adresse vérifiée doit être en *.vercel.app, *.netlify.app ou *.pages.dev ; sinon la preview est ignorée (skipped: "invalid_preview_url"), jamais rabattue sur la production.
Ce que vous voyez
- Dans Déplois : une ligne par preview, badge « Preview », avec l'adresse et le verdict. Pas de Ship Score, pas de reprises T+2 / T+8.
- Sur le commit GitHub : un Check
PostShipintituléPreview vérifiée,Preview : 2 page(s) en échecouPreview : 1 page(s) en échec, hors pack argent, avec le détail par URL. Il suit le réglage de production Exiger un ship vert / Ne bloquer que sur le pack argent (bloquer un merge) : sans cela, une carte sociale cassée sur une preview bloquait le merge d'une équipe réglée pour ne bloquer que sur l'argent. - Sur la page de la preview : l'avant / après visuel contre la production.
Ce qui déclenche une alerte
Rien, tant que Alerter sur les previews est désactivé. Une fois activé, une URL en échec sur la preview part sur vos canaux comme une panne, avec le nom du projet préfixé « Preview — Acme ». Les mêmes règles de silence s'appliquent (règles). Aucun incident n'est ouvert et rien n'est dédoublonné d'une preview à l'autre : deux pushes sur la même branche font deux messages.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Vérification des previews | Non | Oui | Oui |
| Check GitHub sur la preview | Non | Oui | Oui |
| Diff visuel preview contre production | Non | Oui | Oui |
Une preview compte comme un passage complet sur le projet ; elle ne consomme pas de quota d'URL. Voir les plans.
Dépannage
Pourquoi ma preview n'est pas vérifiée ?
Dans l'ordre : la vérification des previews n'est pas activée (skipped: "preview_checks_disabled") ; l'adresse de la preview n'est pas sur un hôte reconnu ; ou votre hébergeur a envoyé l'événement sans adresse exploitable. La réponse du webhook, dans les journaux de l'hébergeur, porte la raison.
Pourquoi toutes mes previews échouent sur une page protégée ?
Si la page exige un en-tête privé, il est envoyé sur la preview comme en production. Si la preview elle-même est protégée par un mot de passe ou une authentification de l'hébergeur (Vercel Deployment Protection, par exemple), PostShip reçoit un 401 : désactivez cette protection pour les previews, ou ajoutez-la comme en-tête privé sur la cible.
Pourquoi le Check bloque la pull request alors que la page tombée n'est pas importante ?
Vous êtes en mode Exiger un ship vert pour merger. Passez sur Ne bloquer que sur le pack argent : le Check devient vert, avec le titre « Preview : 1 page(s) en échec, hors pack argent » pour que l'information reste visible, et seule une page argent le fait encore rougir.