Email, Discord, Slack, Telegram
Qui reçoit quoi, par quel canal, et pourquoi une alerte ne part parfois pas.
Mis à jour le 11 septembre 2026
Sur cette page
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, Slack, Telegram et le webhook sortant 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
Quatre sortes de messages, avec le même libellé partout :
| Sorte | Libellé | Quand |
|---|---|---|
fail | En échec | Une URL vient de passer en échec (ou la panne a changé de nature : un 503 devenu 404) |
recovered | Rétabli | L'URL repasse au vert, et une alerte d'échec était bien partie avant |
mutated | Contenu modifié | Le radar de mutation, une anomalie de latence ou un script tiers qui a changé |
dns | Dérive DNS | Les enregistrements du domaine ont changé depuis le dernier déploiement |
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
[PostShip] Nom du projet — 2 URL(s) en échec, ou — 1 URL(s) rétabli, 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 trois 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 → Paramètres → Notifications. Trois 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, Telegram : Projet → Intégrations, carte Alertes. Voir Connecter Discord, Connecter Slack, Connecter Telegram. 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. Trois 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 4h » 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
| Free | Pro | Team | |
|---|---|---|---|
| Oui | Oui | Oui | |
| Discord, Slack, Telegram | Non | Oui | Oui |
| Webhook sortant | Non | Oui | Oui |
| Alertes d'indexabilité et de dérive DNS | Non (visible dans l'app) | Oui | Oui |
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é.