Comment configurer les alertes Slack lorsque votre site Web tombe en panne

Slack est le canal d'alerte par défaut pour la plupart des équipes d'ingénierie en 2026. La configuration elle-même prend dix minutes. La faire correctement (pour que le canal soit utile lors d'un incident réel et ignorable pendant une semaine calme) nécessite un peu plus de réflexion. Ce guide couvre la configuration pratique, les règles de routage qui préviennent le spam des alertes, et les petites touches qui rendent le canal agréable à vivre pendant des années.

La configuration en 10 minutes

Le motif standard utilise les Incoming Webhooks de Slack. Créez un canal dédié pour les alertes (généralement #alerts ou #ops-alerts), ajoutez une application Incoming Webhook, pointez-la vers le canal, et collez l'URL résultante dans votre outil de surveillance en tant que nouveau canal de notification Slack.

La plupart des moniteurs de disponibilité envoient ensuite un message formaté avec le nom du moniteur, la raison de la défaillance, le code d'état le cas échéant, et un lien vers le tableau de bord. Testez l'intégration avec une défaillance intentionnelle avant de vous y fier. Un moniteur pointé vers une URL intentionnellement cassée est le test de bout en bout le moins cher que vous puissiez exécuter.

Les quatre règles de routage qui préviennent le spam des alertes

Un canal qui reçoit une alerte par trimestre apprend aux gens à regarder. Un canal qui reçoit cinquante alertes par semaine apprend aux gens à mettre en sourdine. Quatre règles de routage maintiennent un ratio alerte-signal honnête.

• Seuil d'alertes d'au moins 3 défaillances consécutives avant de notifier le canal. Une vérification manquée est du bruit. Trois d'affilée, c'est un signal.
• Messages de récupération dans le même canal que la défaillance. Les incidents résolus ont besoin d'un message de fermeture pour que le canal ne reste pas rouge éternellement.
• Canaux séparés pour prod et staging. Les alertes de staging vont à #ops-staging-alerts ; les alertes de prod vont à #ops-prod-alerts. La pollution croisée tue le signal dans les deux.
• Routage par moniteur pour les services hautement prioritaires. Le moniteur du panier d'achat orienté client va à un canal #ops-incidents séparé qui a un engagement d'on-call plus lourd.

Le format de message qui aide vraiment

Les messages Slack par défaut des outils de monitoring sont généralement corrects. Les améliorations proviennent d'une ou deux additions personnalisées qui se révèlent utiles lors d'un vrai incident.

Incluez un lien vers un runbook si vous en avez un. Une petite ligne en bas du message d'alerte qui pointe vers le runbook de réponse aux incidents économise quatre-vingt-dix secondes à l'ingénieur d'astreinte à 3 heures du matin. Incluez un horodatage « previously red at » si le moniteur a oscillé récemment. Les incidents répétés sont de l'or diagnostique lors d'une postmortem.

Quand Slack ne suffit pas

Slack est un canal de chat, pas un système de paging. Trois modes de défaillance ne sont pas résolus en ajoutant des alertes à Slack.

• Incidents nocturnes quand personne ne lit Slack. Un outil de paging (PagerDuty, Opsgenie, Better Stack On-Call) doit se superposer au canal Slack pour une couverture hors heures.
• Perte de notifications mobiles. L'application Slack mobile peut mettre en buffer les notifications pendant les périodes de faible signal. Les alertes critiques ont besoin d'un canal séparé qui contourne complètement Slack.
• Mise en sourdine du canal ou mode focus. Les paramètres de ne-pas-déranger de Slack lui-même font taire les alertes. Un outil de paging ignore DND.

L'hygiène qui garde le canal utile

Trois petites habitudes gardent un canal d'alerte Slack agréable à vivre au bout de six mois.

Épinglez un message runbook en haut du canal. Réagissez avec un emoji pouce levé quand une alerte est en cours d'investigation, pour que les autres lecteurs sachent qu'elle est traitée. Effectuez un examen trimestriel du volume des alertes et élaguez les moniteurs qui produisent plus de bruit que de signal. Le canal qui est nettoyé tous les trimestres reste utile pendant des années.

Configuration de démarrage en 30 minutes

Créez #ops-alerts et #ops-incidents en tant que canaux séparés. Ajoutez le Slack Incoming Webhook à chacun. Configurez votre outil de monitoring pour envoyer les événements DOWN sur un seuil de 3 défaillances consécutives à #ops-alerts. Configurez plutôt les moniteurs orientés client hautement prioritaires vers #ops-incidents. Ajoutez des messages de récupération UP aux deux. Épinglez un message runbook. Testez avec un moniteur intentionnellement cassé. Temps total : trente minutes. Valeur totale : chaque incident futur a un historique propre et scannable dans Slack.