Être alerté sur Slack avant qu'un client ne le remarque, pas après
L’écart entre « quelque chose a cassé » et « quelqu’un l’a su » est là où un incident devient vraiment coûteux — pas la panne elle-même, le délai avant qu’un humain ne soit au courant. Une règle de notification ferme cet écart pour la douzaine d’événements qui méritent vraiment d’interrompre quelqu’un.
Ce qu’est vraiment une règle
Un canal — un webhook entrant Slack, n’importe quelle URL de webhook qui prend un POST JSON, ou une adresse e-mail — limité soit à toutes les applications de l’équipe soit à une application précise, avec une liste à cocher des événements qui devraient l’atteindre. Chaque nouvelle équipe démarre avec une règle déjà configurée, pas une page de réglages vide : un e-mail au propriétaire de l’équipe couvrant les échecs de déploiement, les serveurs hors ligne, les boucles de plantage, et les applications down, modifiable ou supprimable comme n’importe quelle autre règle une fois que vous avez mis en place quelque chose de mieux adapté à votre équipe.
La vraie liste d’événements
Les règles à l’échelle de l’équipe couvrent l’échec/succès de déploiement, un déploiement en attente d’approbation, un serveur qui passe hors ligne, une boucle de plantage, un serveur à court de disque/CPU/mémoire, une application qui échoue ses vérifications de disponibilité ou un certificat qui approche de l’expiration, du nouveau gaspillage de coûts ou une prévision de budget dépassée (liée à Coûts et économies), une recherche de log sauvegardée qui correspond trop souvent, une accumulation de tâches en arrière-plan et sa résorption, une alerte de métrique qui se déclenche et se résout, et des fenêtres de maintenance ou des tâches de données longues qui se terminent.
C’est la plupart de ce qu’une petite équipe câblerait autrement à travers trois ou quatre outils séparés — l’alerting propre d’une page de statut, un SaaS d’alerte de logs, un outil d’anomalie de coûts — comme une seule liste à un seul endroit, chaque événement basculable indépendamment par canal.
Limité à une application quand c’est tout ce qui compte
Settings → General → Notifications sur une application précise ajoute une règle juste pour elle — déploiement échoué/réussi, application down, boucle de plantage, accumulation de tâches, alertes de métriques, et fins de tâches de données. Pour une équipe qui fait tourner plusieurs applications où une seule est vraiment critique, c’est la différence entre un canal de notification que les gens lisent vraiment et un qui se fait mettre en sourdine après la troisième alerte non pertinente sur un projet secondaire.
Ce qu’une règle webhook envoie vraiment
Un vrai POST JSON, pas un vague ping « quelque chose s’est passé » — une charge utile d’alerte de métrique porte event: "metric_alert", status (firing ou resolved), le metric, la value et le threshold qui l’ont déclenchée, et les événements de déploiement incluent la propre note du déploiement. Assez de structure pour router vers ce qu’une équipe utilise déjà pour l’astreinte, sans avoir à extraire un message Slack pour comprendre ce qui s’est vraiment passé.
Séparément, Team → Webhooks gère les webhooks sortants signés destinés à vos propres systèmes à consommer de façon programmatique — un mécanisme différent des règles de notification, qui mérite d’être connu à part puisque les deux résolvent des problèmes voisins mais distincts (alerter un humain contre intégrer un système).
Ce qui est honnêtement encore bêta
La livraison par e-mail dépend du fait que l’envoi d’e-mails soit configuré du côté de Railyard lui-même, et est marquée bêta pour exactement cette raison — tout ce dont on dépend vraiment devrait aussi avoir une règle Slack ou webhook comme second canal, pas l’e-mail seul. Chaque règle a une seule destination; deux canaux Slack veulent dire deux règles, pas une règle avec deux cibles. Les deux sont de petites limites précises, dites clairement plutôt que découvertes le jour où une alerte par e-mail n’arrive pas silencieusement.
Référence complète : Notifications.