Alerte Slack, Discord ou Telegram quand ton site tombe, sans bruit inutile

Trop d'alertes de monitoring : pourquoi on finit par ne plus les lire

Un email d'alerte se perd facilement entre une facture et une newsletter. Un message dans Slack, Discord ou Telegram, lui, arrive dans l'outil que tu as déjà ouvert, sur ton ordinateur comme sur ton téléphone. C'est pour ça que tant de développeurs, d'agences web et de petites équipes y envoient leurs alertes de panne.

Le problème, ce n'est pas d'envoyer le message. C'est ce qui se passe au bout de quelques semaines :

• Les fausses alertes : un délai dépassé isolé, une micro-coupure réseau, et le salon affiche « site en panne » alors que tout va bien. À la troisième fausse alerte, plus personne ne se précipite.
• La répétition : un script qui prévient à chaque vérification envoie un message toutes les cinq minutes pendant toute la panne.
• La tempête : l'hébergeur tombe, et les quinze sites qu'il héberge déclenchent quinze messages en même temps. Le téléphone vibre sans arrêt, et l'information utile (« c'est l'hébergeur ») est noyée.
• Le mauvais destinataire : les alertes du client A arrivent dans le salon où travaille l'équipe du client B, ou dans le canal général, entre deux discussions.
• Les pannes prévues : une mise à jour planifiée qui coupe le site dix minutes déclenche les mêmes alertes qu'une vraie panne.

Résultat : on coupe les notifications du salon, et le jour de la vraie panne, personne ne voit rien. C'est ce qu'on appelle la fatigue d'alerte. Le but de ce guide est de l'éviter dès le départ.

Ce guide parle des alertes de panne de tes sites et de tes API. Pour être prévenu par tes propres scripts (sauvegarde, cron, déploiement), voir plutôt Notification Telegram ou email depuis un script.

La méthode à la main : un script et un webhook

Les trois messageries acceptent des messages venus de l'extérieur par une simple requête HTTP. Il suffit d'une URL secrète, puis d'un curl.

1. Récupérer le webhook Discord, Slack ou Telegram

• Discord : dans les paramètres du salon, Intégrations → Webhooks → Nouveau webhook, puis copie l'URL du webhook. Elle commence par https://discord.com/api/webhooks/. Il faut la permission « Gérer les webhooks » sur le serveur.
• Slack : crée une application Slack, active les Incoming Webhooks et ajoute un webhook pour le canal voulu. Slack te donne une URL en https://hooks.slack.com/services/….
• Telegram : crée un bot avec @BotFather (commande /newbot), envoie-lui un message, puis récupère l'identifiant de la conversation avec getUpdates. Pour un groupe, ajoute d'abord le bot au groupe et écris-y un message avant d'appeler getUpdates. Le pas-à-pas complet est dans le guide Notification Telegram depuis un script.

Chacune de ces URL permet d'écrire dans ton salon : garde-la secrète.

2. Envoyer un message

Le format change un peu d'une messagerie à l'autre : {"content": "…"} pour Discord, {"text": "…"} pour Slack, et les champs chat_id et text pour Telegram.

# Discord
curl -fsS -H "Content-Type: application/json" \
  -d '{"content": "Site en panne : https://exemple.fr"}' \
  "https://discord.com/api/webhooks/VOTRE_ID/VOTRE_JETON"

# Slack
curl -fsS -H "Content-Type: application/json" \
  -d '{"text": "Site en panne : https://exemple.fr"}' \
  "https://hooks.slack.com/services/VOTRE/URL/SECRETE"

# Telegram
curl -fsS -X POST "https://api.telegram.org/botVOTRE_JETON_BOT/sendMessage" \
  -d chat_id=VOTRE_CHAT_ID \
  --data-urlencode "text=Site en panne : https://exemple.fr"

3. Script d'alerte Discord ou Slack quand le site est down

Reste à vérifier le site régulièrement. Un script lancé par cron toutes les cinq minutes fait l'affaire. Pour ne pas envoyer un message à chaque passage pendant toute la panne, il garde une trace de l'état dans un fichier, et prévient aussi quand le site revient :

#!/usr/bin/env bash
# check-site.sh : à lancer par cron, par exemple */5 * * * *
URL="https://exemple.fr"
WEBHOOK="https://discord.com/api/webhooks/VOTRE_ID/VOTRE_JETON"
STATE="$HOME/.check-site.down"

send() {
  curl -fsS -H "Content-Type: application/json" \
    -d "{\"content\": \"$1\"}" "$WEBHOOK" > /dev/null
}

code=$(curl -sL -o /dev/null -w '%{http_code}' --max-time 10 "$URL")

if [ "$code" -lt 200 ] || [ "$code" -ge 400 ]; then
  # Panne : on ne prévient qu'une fois
  if [ ! -f "$STATE" ]; then
    send "🔴 $URL est en panne (code $code)" && touch "$STATE"
  fi
else
  # Retour à la normale : on prévient, puis on oublie la panne
  if [ -f "$STATE" ]; then
    send "🟢 $URL est rétabli" && rm -f "$STATE"
  fi
fi

Quand le serveur ne répond pas du tout, curl renvoie le code 000 : le script le compte comme une panne. Pour Slack, remplace content par text. Le script contient l'URL secrète du webhook : rends-le lisible par toi seul (chmod 700 check-site.sh) et ne le publie pas dans un dépôt Git.

Les limites de la méthode à la main

Pour un site, ce script rend service. Mais il reste fragile, et il ne règle aucun des problèmes de bruit cités plus haut :

• Pas de second essai. Un seul délai dépassé, et l'alerte part. Pour l'éviter, il faut ajouter un nouvel essai quelques secondes plus tard, et distinguer une erreur réseau passagère d'une vraie erreur du serveur.
• Pas de regroupement. Avec un script par site, une panne d'hébergeur donne autant de messages que de sites.
• Pas de routage. Envoyer les alertes du client A dans un salon et celles du client B dans un autre, c'est un webhook à recopier dans chaque script, à mettre à jour partout le jour où il change.
• Pas de pause. Pour une maintenance prévue, il faut penser à commenter la ligne de la crontab, puis à la remettre.
• Pas de vrai réessai. Si Discord ou Slack ne répond pas, le script retente seulement au passage suivant, cinq minutes plus tard. Si le site est revenu entre-temps, la panne n'est jamais signalée.
• Le script tombe avec le serveur. S'il tourne sur la même machine que le site, une panne de la machine arrête aussi la surveillance : aucun message. Il faut une deuxième machine, ailleurs.
• Pas d'historique. Combien de pannes ce mois-ci, et combien de temps ont-elles duré ? Le seul journal, c'est le fil du salon.

Chaque point se règle avec un peu de code en plus. C'est exactement le travail d'un service de surveillance.

Alerte Slack, Discord ou Telegram quand un site est en panne ou hors ligne, avec Pinguro

Pinguro vérifie tes sites depuis l'extérieur et envoie les alertes sur des canaux : email, Slack, Discord, Telegram ou webhook. Un canal se crée une fois, et sert à tous les monitors du workspace.

1. Ajoute un canal

Dans le tableau de bord, ouvre Alertes dans la barre latérale, puis + Ajouter un canal. Choisis le Type (Email, Slack, Discord, Webhook ou Telegram) et donne-lui un Nom parlant, par exemple « Discord production ».

2. Colle l'adresse d'envoi

• Slack : le champ Slack Incoming Webhook URL attend l'URL en https://hooks.slack.com/….
• Discord : le champ Discord Webhook URL attend l'URL en https://discord.com/api/webhooks/….
• Telegram : le champ URL Telegram attend l'adresse complète https://api.telegram.org/bot<TOKEN>/sendMessage?chat_id=<ID>, avec le jeton de ton bot et l'identifiant de la conversation. Tu peux aussi les saisir séparément (Bot token et Chat ID), via Saisir manuellement. Pour un groupe Telegram, l'identifiant est négatif.

Clique sur Enregistrer. Le détail des étapes Telegram est dans la documentation des canaux d'alerte.

3. Teste

Le bouton Tester du canal envoie une fausse alerte de panne, pour un monitor nommé « Test alert » sur https://example.com. Si l'envoi est refusé, le bouton affiche Échec : URL mal copiée, webhook supprimé, bot retiré du groupe… Si le bouton affiche Envoyé ✓ mais que rien n'arrive, vérifie que l'URL vise le bon salon (10 tests par heure au plus).

À quoi ressemblent les messages

Une panne donne un message avec le nom du monitor, son adresse et la raison en français. Exemple sur Slack :

🔴 Boutique est DOWN
https://boutique.exemple.fr
Raison : Code HTTP 503 (attendu 200–299)

Sur Discord, le même contenu arrive sous forme de carte rouge, avec un champ Raison ; sur Telegram, en une ligne : 🔴 DOWN — Boutique (https://boutique.exemple.fr), suivie de la raison. Au retour à la normale, un message vert : « Boutique est rétabli » sur Slack, « Boutique rétabli » sur Discord, 🟢 UP — Boutique (…) sur Telegram.

Les messages n'ajoutent aucune mention (@here, @everyone) : c'est le réglage de notification du salon, chez toi, qui décide qui est prévenu et comment.

Réduire le bruit : ce que Pinguro fait pour toi

Un second essai avant de déclarer la panne

Quand une vérification échoue pour une raison qui peut être passagère (délai dépassé, erreur de connexion, résolution DNS échouée, connexion TCP refusée), Pinguro refait un essai 2 secondes plus tard. Le site n'est déclaré en panne que si ce second essai échoue aussi. Une erreur franche, comme un code HTTP 500 ou un mot-clé absent de la page, n'est pas réessayée : le serveur a répondu, la panne est réelle.

Une alerte par panne, pas une par vérification

L'alerte de panne part une seule fois, au début. Tant que le site reste en panne, les vérifications suivantes n'envoient rien. Quand il revient, un message « rétabli » ferme la panne. Pas besoin de fichier d'état ni de script : c'est le fonctionnement normal.

Le regroupement des alertes

C'est le réglage qui évite la tempête. Quand le regroupement est activé, l'alerte attend environ 2 minutes de plus. Si au moins 3 sites tombent quasiment en même temps (typiquement une panne d'hébergeur), tu reçois un seul message qui les liste tous :

🔴 12 sites DOWN : Boutique, Blog, Espace client, API, …

La liste affiche jusqu'à 20 noms, puis « … et N autres ». Les retours à la normale suivent la même règle (« 12 sites rétablis »). En dessous de 3 sites, chaque panne arrive en message normal, avec ce petit délai en plus.

Le réglage se trouve sur la page Workspaces, interrupteur Regroupement des alertes (modifiable par le propriétaire et les admins du workspace). Un nouveau workspace démarre sans regroupement : les alertes partent dès que la panne est confirmée. À toi de choisir entre réactivité et calme.

Avec les groupes de monitors (plans payants), chaque groupe peut aussi suivre son propre réglage : Comme le workspace, Toujours regrouper ou Jamais — alerte immédiate. Pratique pour regrouper un parc de sites hébergés au même endroit, tout en gardant l'alerte immédiate pour un client sensible. Le regroupement se fait groupe par groupe : deux groupes qui tombent en même temps reçoivent chacun leur message, jamais un mélange des deux.

Le routage par groupe : chaque alerte au bon endroit

Par défaut, un canal reçoit les alertes de tous les monitors du workspace. Avec les groupes, tu peux le restreindre : dans Alertes, édite le canal, et dans Routing par groupe, passe de Tous les monitors du workspace à Certains groupes uniquement, puis coche les groupes voulus.

Exemple pour une agence web : un Discord Client A qui ne reçoit que le groupe du client A, un Slack Client B pour le client B, et un email d'astreinte qui reçoit tout. Attention : un canal limité à certains groupes ne reçoit pas les alertes des monitors qui ne sont rangés dans aucun groupe.

Les fenêtres de maintenance

Pour une intervention prévue, ouvre Maintenance, puis + Nouvelle maintenance : un Titre, un Début, une Fin, et les Monitors concernés (Tous mes monitors ou une Sélection). Pendant la fenêtre, les vérifications continuent, mais aucune alerte ne part pour ces monitors, et les minutes de la fenêtre ne comptent pas dans le pourcentage de disponibilité.

Si le site est toujours en panne à la fin de la fenêtre, l'alerte part à la première vérification qui suit : une mise à jour qui a mal tourné ne passe pas inaperçue. Les fenêtres de maintenance sont disponibles sur tous les plans.

Les sites lents et les délais dépassés

Deux réglages par monitor évitent les alertes qui n'appellent pas d'action :

• La lenteur : dans la section Performance d'un monitor, le Seuil "lent" (de 200 à 30 000 ms) marque le site LENT quand il répond au-delà. L'alerte de lenteur est désactivée par défaut ; si tu l'actives, tu reçois un message quand le site devient lent, et un autre quand il retrouve une latence normale. Jamais un par vérification.
• Les délais dépassés : pour un site régulièrement lent à répondre, la case M'alerter si le site est totalement injoignable (timeout = panne), dans la section Notifications d'un monitor HTTP, peut être décochée. La panne reste enregistrée dans l'historique et compte dans la disponibilité, seule la notification disparaît. Les autres pannes (code d'erreur, connexion refusée…) continuent d'alerter.

Rien n'est perdu si la messagerie ne répond pas

Si Slack, Discord, Telegram ou le serveur d'emails ne répond pas au moment d'envoyer une alerte de panne ou de retour à la normale, Pinguro réessaie vers ce canal, avec des essais de plus en plus espacés, pendant 24 heures au plus. Les canaux qui ont déjà reçu l'alerte ne la reçoivent pas une seconde fois, et un « rétabli » n'arrive jamais avant sa panne.

Bonnes pratiques

Un salon dédié aux alertes

Ne mélange pas les alertes avec les conversations. Un salon #alertes-prod sur Slack ou Discord, ou un groupe Telegram dédié, ne contient que ça : chaque message compte. Règle ce salon pour être notifié à chaque nouveau message, et coupe plutôt le bruit des autres salons.

Séparer le critique du reste

Le site qui fait ton chiffre d'affaires et le site de démonstration d'un ancien projet ne méritent pas la même urgence. Range-les dans des groupes différents, et route chaque groupe vers un canal différent : le critique vers le salon que tu surveilles de près, le reste vers un salon que tu consultes une fois par jour.

Deux canaux pour l'essentiel

Slack, Discord et Telegram peuvent eux aussi tomber en panne, ou une notification peut être mise en sourdine par erreur. Pour les sites importants, ajoute un deuxième canal, par exemple l'email : chaque canal actif reçoit l'alerte de son côté.

Régler plutôt que couper

Un monitor qui alerte trop souvent cache un problème : seuil de lenteur trop bas, vérification d'une page qui redirige vers une page de connexion, site vraiment instable. Corrige le réglage ou la cause, mais ne coupe pas le canal. Si tu dois vraiment couper un canal quelques heures, l'interrupteur dans Alertes le met en pause sans le supprimer.

Planifier les maintenances avant de les faire

Une fenêtre de maintenance créée avant une mise à jour évite la fausse alerte, et prévient aussi tes visiteurs : la page de statut publique affiche un bandeau Maintenance prévue, puis Maintenance en cours. Pour aller plus loin sur la page de statut, voir Status page publique : ce que tes clients attendent vraiment.

Ce que permet chaque plan

Sur tous les plans : second essai avant l'alerte, une alerte par panne et un message de retour à la normale, regroupement des alertes par workspace, fenêtres de maintenance, alertes de lenteur et réglage des délais dépassés. Les plans payants ne sont pas encore ouverts : aujourd'hui, seul le plan gratuit est disponible. Le détail de chaque canal est dans la documentation des canaux d'alerte.

Questions fréquentes

Pourquoi mon alerte arrive-t-elle quelques minutes après la panne ?

Deux raisons s'additionnent. La panne est détectée à la vérification suivante, donc au rythme de l'intervalle du monitor (jusqu'à 15 minutes sur le plan gratuit). Ensuite, si le regroupement est activé, l'alerte attend environ 2 minutes pour réunir les pannes simultanées. Sans regroupement, elle part dès la vérification qui confirme la panne.

Puis-je recevoir la même alerte sur Slack et par email ?

Oui. Chaque canal actif du workspace reçoit l'alerte, sauf s'il est limité à certains groupes. Si la même adresse email figure sur plusieurs canaux, elle ne reçoit l'alerte qu'une fois.

Est-ce que je suis prévenu quand le site revient ?

Oui, par un message « rétabli », sur les mêmes canaux que l'alerte de panne. Si la panne n'avait pas été annoncée (délai dépassé avec les alertes de délai désactivées, par exemple), le retour à la normale ne l'est pas non plus.

Que se passe-t-il si dix sites tombent en même temps ?

Sans regroupement, dix messages. Avec le regroupement activé, si les dix pannes sont confirmées quasiment en même temps (typiquement une panne d'hébergeur), un seul message qui liste les dix sites, environ 2 minutes après la panne, puis un seul message quand ils reviennent. Avec des groupes, chaque groupe reçoit son propre message.

Les alertes passent-elles aussi par un webhook ?

Oui, sur les plans payants (Solo et au-delà) : le canal webhook envoie un JSON à ton propre serveur, pour brancher un outil maison. Il n'est jamais regroupé : il part tout de suite, un message par monitor. Le format est décrit dans la documentation.

Conclusion

Envoyer une alerte sur Slack, Discord ou Telegram prend cinq minutes avec un webhook et curl. La rendre fiable et supportable prend plus de temps : un second essai pour écarter les fausses alertes, une seule alerte par panne et un message de retour, un regroupement pour les pannes d'hébergeur, un routage pour que chaque alerte arrive au bon endroit, et des fenêtres de maintenance pour les interventions prévues.

Avec ces réglages, chaque message dans ton salon d'alertes veut dire quelque chose. Et c'est la seule façon de continuer à les lire le jour où ça compte.