Email, Discord, Slack

Une alerte part quand une URL tombe en échec, quand elle est rétablie, quand son contenu a changé après un déploiement, ou quand le DNS du domaine a bougé. L'email est le canal de base, sur tous les plans. Discord et Slack, sur tous les plans, et le webhook sortant, avec un plan payant, reçoivent la même chose en plus, projet par projet. Rien n'est envoyé tant que tout est vert : c'est le principe du produit, pas une option.

Ce que PostShip envoie

4 sortes de messages, avec le même libellé partout :

Chaque élément porte l'URL, une phrase qui nomme la cause (« La page répond 200 mais un fichier statique est introuvable : /app.js. », « Le prix n'apparaît plus sur … »), le statut HTTP et le TTFB, et un lien vers le détail de l'URL. Chaque phrase vient d'une table de codes, la même sur tous les canaux ; rien n'est généré par un modèle.

Le sujet de l'email

Nom du projet — 2 URLs en échec, ou — 1 URL rétablie, ou — dérive DNS détectée. Le corps commence par le récapitulatif (« 2 en échec, 0 rétablis. ») puis une carte par URL. Quand l'alerte suit un déploiement, le récapitulatif dit « Depuis le dernier déploiement : … ».

Quand plusieurs URL tombent ensemble

À partir de 3 URL qui tombent en même temps pour la même raison — le serveur ne répond pas, ou il répond la même erreur 5xx — PostShip ne fait pas 3 cartes mais une seule, titrée Site injoignable · 7 URL ou Erreur serveur 503 · 7 URL, avec la phrase qui va avec : « 7 URL ne répondent plus en même temps : c'est le site entier, pas ces pages. Regardez l'hébergeur ou le DNS avant les pages. » La liste s'arrête à 6 URL, puis « … et 3 autres ». Un échec de contenu (balise absente, fichier manquant) n'est jamais regroupé : ce n'est pas une panne du site.

« Ce n'est peut-être pas vous »

Quand quelque chose tombe, PostShip lit l'état des fournisseurs que votre site utilise (Vercel, Cloudflare, Supabase…). Si l'un d'eux signale un incident, l'alerte ajoute sous le récapitulatif : « Ce n'est peut-être pas vous : Vercel signale un incident (Elevated errors on deployments). » C'est la première chose à savoir avant de chercher chez soi.

Régler

• Email : Compte → Notifications. 3 cases : « Une URL tombe en échec » (décocher coupe tous les emails d'alerte), « Une URL est rétablie », « Le contenu a changé après un déploiement ». Ces cases ne concernent que l'email.
• Discord, Slack : Projet → Paramètres → Intégrations, section Sortant, une carte par salon. Voir Connecter Discord, Connecter Slack. Ces canaux reçoivent tout, y compris les rétablissements.
• Tester : le bouton « Envoyer une alerte de test » sur Intégrations envoie une vraie alerte, sur tous les canaux branchés, en respectant les règles du projet. 3 tests par minute au plus.

Ce qui déclenche une alerte, et ce qui la retient

Une alerte d'échec part à la transition : quand la série d'échecs consécutifs atteint le nombre choisi dans Règles (1 par défaut). Une page en panne toute la nuit n'écrit qu'une fois, pas 144 fois. Elle réécrit seulement si la panne change de nature. Une alerte identique (même URL, même empreinte) n'est jamais renvoyée en moins de 10 minutes.

Ce qui retient un envoi, sur tous les canaux à la fois :

• Les alertes coupées (« Couper 1 h / 4 h / 24 h » sur la page Incidents ou dans Règles).
• Une fenêtre de maintenance, ponctuelle ou récurrente, en cours.
• Les heures calmes du projet.
• Le silence d'une URL précise (« Couper les alertes 4 h » dans le menu d'une URL) : seule cette URL est retirée du message.

Dans tous ces cas la vérification a bien tourné et l'historique est écrit : c'est l'envoi qui s'arrête, pas la surveillance.

Limites et plans

Voir les plans.

Dépannage

Pourquoi l'email est arrivé mais pas le message Discord ?

Un webhook supprimé côté Discord répond 404 : PostShip le considère comme un échec, ne l'inscrit pas comme envoyé, et l'email part quand même. Reconnectez le salon depuis Intégrations. Chaque canal est indépendant : la panne de l'un n'empêche pas les autres.

Pourquoi je ne reçois pas les rétablissements ?

Soit la case « Une URL est rétablie » est décochée sur votre compte, soit aucune alerte d'échec n'était partie pour cette panne (par exemple avec une confirmation à 3 échecs et une panne de 2 passages) : PostShip n'annonce pas le rétablissement d'un incident qu'il ne vous a jamais signalé.

Connecter Discord

Recevoir les alertes dans un salon Discord, en collant l'adresse d'un webhook. Sur tous les plans.

Discord reçoit les alertes par un webhook : une adresse que Discord crée pour un salon, et que vous collez dans PostShip. Pas de bot ajouté au serveur, et c'est compris dans tous les plans, Découverte aussi. Il suffit que quelqu'un qui a la permission « Gérer les webhooks » vous donne l'adresse.

Créer le webhook

Le webhook se crée depuis Discord, dans les paramètres du salon.

1. Dans Discord, faites un clic droit sur le salon → Modifier le salon → Intégrations → Webhooks.
2. Créez un webhook, donnez-lui un nom (« PostShip »), puis cliquez sur « Copier l'URL du webhook ».
3. Dans PostShip, ouvrez Projet → Paramètres → Intégrations, collez l'URL dans la carte Discord et enregistrez. Seule une adresse https://discord.com/api/webhooks/... est acceptée.

« Tester les alertes », sur la même page, envoie un message d'essai dans le salon.

Ce que vous recevez

Un message par vérification qui change quelque chose, posté sous le nom « PostShip » : un encart coloré selon l'état (rouge en échec ou dérive DNS, vert rétabli, orange contenu modifié), le titre (« 2 URLs en échec », « Site injoignable · 7 URL »), le récapitulatif, puis un champ par URL avec la raison de l'échec en clair, le statut HTTP et le TTFB, et un lien vers la page de l'URL. Au pied : « Tableau de bord · Incidents · Gérer les alertes ». Au-delà de 8 URL dans un même message, les autres sont comptées (« +3 autres URL sur le tableau de bord »). Le détail des libellés est sur les canaux d'alerte.

Le même salon reçoit aussi les messages d'équipe, en texte simple : « marie prend en charge l'incident » (acquittement), l'escalade et, avec un plan payant, le résumé quotidien.

Couper ou changer de salon

Le bouton « Désactiver » supprime l'URL enregistrée : PostShip cesse immédiatement d'y écrire. Pour changer de salon, collez le webhook du nouveau salon à la place. Pour faire taire les alertes sans rien débrancher, utilisez « Couper 1 h / 4 h / 24 h », les heures calmes ou une fenêtre de maintenance.

Limites et plans

Le plan qui compte est celui du propriétaire du projet. Voir les plans.

Dépannage

Pourquoi l'URL est-elle refusée ?

Seules les adresses https://discord.com/api/webhooks/... sont acceptées. Le lien d'invitation d'un serveur ou l'adresse d'un salon ne sont pas des webhooks : suivez les étapes ci-dessus pour en créer un.

Pourquoi un @everyone dans mon alerte ne mentionne personne ?

C'est voulu : ce qui vient de votre site (un titre de page, un extrait de contenu modifié) est neutralisé avant d'être écrit dans le message, pour qu'un texte récupéré sur une page surveillée ne fasse jamais sonner toute l'équipe.

Connecter Slack

Recevoir les alertes dans un canal Slack, en collant l'adresse d'un webhook entrant. Sur tous les plans.

Slack reçoit les alertes par un webhook entrant : une adresse que Slack vous donne pour un canal, et que vous collez dans PostShip. C'est compris dans tous les plans, Découverte aussi.

Créer le webhook

Le webhook entrant se crée depuis votre propre application Slack.

1. Rendez-vous sur https://api.slack.com/apps et créez une application (« From scratch »), rattachée à votre espace de travail.
2. Dans le menu de gauche, ouvrez « Incoming Webhooks » et activez l'option.
3. Cliquez sur « Add New Webhook to Workspace », choisissez le canal, autorisez, puis copiez l'URL qui commence par https://hooks.slack.com/services/.
4. Dans PostShip, ouvrez Projet → Paramètres → Intégrations, collez l'URL dans la carte Slack et enregistrez. Seule une adresse hooks.slack.com est acceptée.

« Tester les alertes », sur la même page, envoie un message d'essai dans le canal.

Ce que vous recevez

Un message structuré : un titre avec le projet et l'état (« Mon site — 2 URLs en échec »), un rappel du nombre d'URL en échec, rétablies ou modifiées, une section par URL avec la raison de l'échec en clair, le statut HTTP et le TTFB, et 3 boutons : « Ouvrir le tableau de bord », « Incidents », « Gérer les alertes ». Le bouton principal passe en rouge quand quelque chose est en échec ou qu'une dérive DNS est détectée. Au-delà de 8 URL, les autres sont comptées. Le détail des libellés est sur les canaux d'alerte.

Le même canal reçoit aussi les messages d'équipe en texte simple : prise en charge, escalade et, avec un plan payant, le résumé quotidien.

Couper ou changer de canal

Le bouton « Désactiver » supprime l'URL enregistrée. Pour changer de canal, créez un webhook pour le nouveau canal et collez-le à la place : un webhook entrant Slack est lié à un seul canal. Pour faire taire les alertes sans rien débrancher, voir les règles et la maintenance.

Limites et plans

Le plan qui compte est celui du propriétaire du projet. Voir les plans.

Dépannage

Pourquoi l'URL est-elle refusée ?

Seules les adresses https://hooks.slack.com/... sont acceptées. L'adresse d'un canal (https://acme.slack.com/archives/...) n'est pas un webhook : suivez les étapes ci-dessus pour en créer un.

Pourquoi mon message Slack ne montre que 8 URL ?

Slack limite la taille d'un message. Les URL suivantes sont comptées (« +4 autres URL — voir le tableau de bord ») et la page Incidents les liste toutes.

Webhook sortant

Disponible avec les plans Pro et Pro Plus.

Recevoir chaque alerte en JSON signé HMAC sur votre propre endpoint, et choisir les événements.

En plus de l'email, de Discord et de Slack, PostShip peut envoyer chaque alerte en POST vers une URL HTTPS à vous, signée en HMAC-SHA256. C'est le canal des automates : ouvrir un ticket, couper un déploiement, allumer une lampe. Il obéit aux mêmes règles que les autres canaux (silence, heures calmes, confirmation, maintenance) parce qu'il reçoit exactement le même lot d'éléments, une fois filtré.

Ce que PostShip envoie

Une requête par sorte d'événement : un lot qui mêle un échec et un rétablissement devient 2 requêtes, une fail et une recovered.

POST /hooks/postship HTTP/1.1
Content-Type: application/json
X-PostShip-Event: fail
X-PostShip-Version: 1
X-PostShip-Delivery: 6d0c1a2e-…
X-PostShip-Signature: sha256=3f1a…e9c2

{
  "version": 1,
  "id": "6d0c1a2e-…",
  "event": "fail",
  "projectId": "8b2f…",
  "projectName": "Mon site",
  "at": "2026-09-11T14:03:12.418Z",
  "items": [
    { "url": "https://monsite.fr/checkout", "httpStatus": 503, "missing": null },
    { "url": "https://monsite.fr/", "httpStatus": 200, "missing": ["asset:script:/app.js"] }
  ],
  "test": false
}

La signature

X-PostShip-Signature vaut sha256= suivi de l'empreinte HMAC-SHA256 hexadécimale du corps brut de la requête, calculée avec votre secret. Vérifiez-la avant de lire le contenu : sans elle, n'importe qui connaissant l'URL peut vous faire ouvrir un ticket.

import { createHmac, timingSafeEqual } from "node:crypto";

export function verifier(corpsBrut, signature, secret) {
  const attendue = "sha256=" + createHmac("sha256", secret).update(corpsBrut).digest("hex");
  const a = Buffer.from(attendue);
  const b = Buffer.from(signature ?? "");
  return a.length === b.length && timingSafeEqual(a, b);
}

Le corps doit être lu tel quel (texte brut) avant tout décodage JSON : la signature porte sur les octets envoyés, et un re-sérialisation change l'ordre des clés ou les espaces.

Rejouer

Chaque livraison est gardée telle qu'envoyée — les 20 dernières par projet, avec le statut reçu — dans la carte Webhook sortant. « Rejouer » renvoie le même corps sous le même id, signé avec le secret du moment, avec un en-tête X-PostShip-Replay: true en plus. Un récepteur qui dédoublonne sur id n'ouvrira pas 2 tickets ; un récepteur qui était en panne reçoit ce qu'il a manqué. Le rejeu est un geste d'éditeur du projet, jamais automatique.

Ce que PostShip exige de votre endpoint

• Une URL HTTPS publique. Une adresse privée, locale ou qui résout vers un réseau interne est refusée à l'enregistrement, et de nouveau à chaque envoi.
• Une réponse 2xx en moins de 4 secondes. Au-delà, l'envoi est abandonné, sans nouvel essai.
• Pas de redirection : un 3xx n'est pas suivi, il compte comme un échec. Le corps signé ne doit pas être remis à un autre hôte que celui que vous avez déclaré.

Un endpoint qui échoue n'empêche ni les autres canaux ni le passage suivant : l'erreur est notée côté PostShip, rien d'autre.

Régler

Projet → Paramètres → Intégrations, section « Sortant », carte « Webhook sortant ».

1. Collez l'URL dans « URL du webhook sortant » et enregistrez.
2. Cliquez sur « Régénérer le secret ». Le secret (64 caractères hexadécimaux) s'affiche une seule fois : « Copiez ce secret maintenant — il ne sera plus jamais affiché. » Rangez-le dans une variable d'environnement de votre côté. Tant qu'aucun secret n'existe, rien n'est envoyé.
3. Cliquez sur « Envoyer un test » : une requête fail avec un seul élément https://example.com en 500 et "test": true. Votre endpoint peut ainsi distinguer une sonde d'un vrai incident.
4. Choisissez les « Événements envoyés » : Échec, Rétablissement, Changement, DNS. Tout coché par défaut. Décocher tout est refusé : « Choisissez au moins un événement — ou désactivez le webhook. »

« Désactiver » efface l'URL et le secret. « Régénérer le secret » invalide l'ancien immédiatement.

Ce qui déclenche un envoi

Exactement ce qui déclenche une alerte sur les autres canaux, voir Email, Discord, Slack et Règles : transition d'échec, rétablissement d'un incident signalé, contenu modifié après déploiement, dérive DNS. Les envois retenus par le silence, les heures calmes ou une maintenance ne sont pas rejoués. Le tri par événement se fait ici et nulle part ailleurs : les autres canaux reçoivent tout.

Limites et plans

Voir les plans. Pour lire l'état d'un projet plutôt que d'attendre qu'il vous écrive, voir l'API.

Dépannage

Pourquoi « Envoyer un test » répond « Configurez d'abord l'URL et générez un secret » ?

Les deux sont nécessaires : sans secret, PostShip ne signe pas, donc n'envoie pas. Cliquez sur « Régénérer le secret ».

Pourquoi la signature ne correspond jamais ?

Vous vérifiez sans doute le JSON re-sérialisé plutôt que le corps brut. Lisez le corps en texte avant JSON.parse, calculez le HMAC dessus, et comparez à la valeur après sha256=.

Pourquoi mon endpoint reçoit fail mais jamais recovered ?

Regardez les cases « Événements envoyés ». Et un rétablissement n'est envoyé que si l'échec l'avait été : voir Règles.

Résumé quotidien

Disponible avec les plans Pro et Pro Plus.

Un message chaque matin à 8 h sur vos salons : taux de la nuit, incidents ouverts, déploiements de la veille.

Une alerte dit qu'il se passe quelque chose ; le silence ne dit pas que tout va bien, il dit aussi bien que PostShip est tombé. Un message à heure fixe, tous les jours, est la seule preuve qu'un silence est un bon silence. Et pour une équipe, c'est le point du matin sans réunion : le taux de la nuit, ce qui est encore rouge, ce qui a été déployé. Il part sur les salons du projet, jamais par email.

Ce que PostShip envoie

À 8 h, dans le fuseau du projet, sur chaque salon branché (Discord, Slack), un message texte :

Tout est au vert — Mon site
Taux de réussite sur 24 h : 99,7 % (720 vérifications)
Aucun déploiement de production hier.
Budget d'erreur (99,9 %) : 3 h 12 min restantes.
https://postship.fr/…

1 incident en cours — Mon site
Taux de réussite sur 24 h : 96,2 % (720 vérifications)
• https://monsite.fr/checkout — /checkout répond 503.
2 déploiements de production sur 24 h.
https://postship.fr/…

Ligne par ligne :

Court, exprès : on le lit sur un téléphone.

Régler

Projet → Alertes → Notifications, section « Chaque matin » — ou sous les 3 salons, dans Projet → Paramètres → Intégrations : l'interrupteur « Résumé chaque matin à 8 h ». Il s'enregistre tout seul. Sans aucun salon branché, il reste grisé et la ligne le dit : « Branchez d'abord un salon. »

L'heure n'est pas réglable, le fuseau si : c'est celui des heures calmes du projet (Projet → Alertes → Règles, carte « Heures calmes », champ Fuseau), le seul fuseau qu'un projet connaît. Sans réglage, Europe/Paris.

Quand il part

Le moteur de PostShip tourne toutes les 2 minutes, quel que soit le plan. Le résumé part au premier passage après 8 h locales qui trouve qu'il n'est pas encore parti aujourd'hui : un passage manqué à 8 h 00 ne repousse pas le résumé à demain, il part à 8 h 05. Un seul par jour civil local, quel que soit le nombre de passages ; 2 passages qui se chevauchent ne peuvent pas l'envoyer 2 fois.

Il part même si tout est vert : c'est son rôle. Il part aussi pendant les heures calmes, une maintenance ou une coupure « Couper 24 h » : un rendez-vous ne se coupe pas comme une alerte. Un salon qui a répondu une erreur (webhook supprimé) ne bloque pas les autres.

Limites et plans

Le plan qui compte est celui du propriétaire du projet. Un projet retombé en Découverte garde son réglage mais ne reçoit plus rien, comme ses alertes de salon. Voir les plans.

Dépannage

Pourquoi le résumé arrive à 9 h ?

Le fuseau du projet n'est pas le vôtre. Réglez le champ Fuseau des heures calmes dans Règles : le résumé le suit.

Pourquoi le résumé n'est pas arrivé ce matin ?

3 causes possibles : aucun salon branché (la case le signale), tous les salons ont refusé le message (webhook supprimé, bot retiré du groupe : reconnectez depuis Intégrations), ou le plan du propriétaire ne le permet plus.

Pourquoi le taux du résumé diffère de celui de la page Statut ?

Le résumé compte tous les passages du projet sur 24 h, toutes URL confondues. La page de statut ne compte que les composants qu'elle affiche, sur sa propre fenêtre. Voir Page de statut.