Per Slack benachrichtigt werden, bevor ein Kunde es merkt, nicht danach
Die Lücke zwischen „etwas ist kaputt“ und „jemand hat es bemerkt“ ist der Punkt, an dem ein Incident wirklich teuer wird – nicht der Fehler selbst, sondern die Verzögerung, bevor ein Mensch davon weiß. Eine Benachrichtigungsregel schließt diese Lücke für das knappe Dutzend Events, die es tatsächlich wert sind, jemanden zu unterbrechen.
Was eine Regel eigentlich ist
Ein Kanal – ein Slack Incoming Webhook, eine beliebige Webhook-URL, die einen JSON-POST entgegennimmt, oder eine E-Mail-Adresse – zugeordnet entweder jeder App im Team oder einer bestimmten App, mit einer Checkliste, welche Events ihn erreichen sollen. Jedes neue Team startet schon mit einer konfigurierten Regel, nicht mit einer leeren Einstellungsseite: eine E-Mail an den Team-Owner bei Deploy-Fehlern, offline gegangenen Servern, Crash-Loops und ausgefallenen Apps – bearbeitbar oder löschbar wie jede andere Regel, sobald du etwas Passenderes für dein Team eingerichtet hast.
Die tatsächliche Event-Liste
Team-weite Regeln decken ab: Deploy-Fehler/-Erfolg, ein Deploy, das auf Freigabe wartet, einen offline gehenden Server, einen Crash-Loop, einen Server mit knappem Speicherplatz/CPU/RAM, eine App, die ihre Uptime-Checks nicht besteht, oder ein bald ablaufendes Zertifikat, neue Kostenverschwendung oder eine überschrittene Budgetprognose (verknüpft mit Kosten und Einsparungen), eine gespeicherte Log-Suche, die zu häufig anschlägt, einen sich aufbauenden und wieder abbauenden Job-Rückstau, einen auslösenden und sich erholenden Metrik-Alarm, sowie abgeschlossene Wartungsfenster oder lang laufende Datenjobs.
Das ist der größte Teil dessen, was ein kleines Team sonst über drei oder vier separate Tools verdrahten müsste – die eigene Alarmierung einer Statusseite, ein Log-Alarmierungs-SaaS, ein Kostenanomalie-Tool – jetzt als eine Liste an einem Ort, jedes Event unabhängig pro Kanal umschaltbar.
Auf eine App beschränkt, wenn nur das zählt
Einstellungen → Allgemein → Benachrichtigungen bei einer bestimmten App fügt eine Regel nur für sie hinzu – Deploy fehlgeschlagen/erfolgreich, App down, Crash-Loop, Job-Rückstau, Metrik-Alarme, abgeschlossene Datenjobs. Für ein Team mit mehreren Apps, von denen nur eine wirklich kritisch ist, ist das der Unterschied zwischen einem Benachrichtigungskanal, den Leute tatsächlich lesen, und einem, der nach dem dritten irrelevanten Alarm zu einem Nebenprojekt stummgeschaltet wird.
Was eine Webhook-Regel wirklich sendet
Ein echter JSON-POST, kein vages „irgendwas ist passiert“-Ping – das Payload eines Metrik-Alarms trägt event: "metric_alert", status (firing oder resolved), die metric, den value und den threshold, der ausgelöst hat, und Deploy-Events enthalten die Notiz des Deploys selbst. Genug Struktur, um in das zu routen, was ein Team für den Bereitschaftsdienst schon nutzt, ohne eine Slack-Nachricht zu screen-scrapen, um herauszufinden, was tatsächlich passiert ist.
Getrennt davon kümmert sich Team → Webhooks um signierte, ausgehende Webhooks, die für die eigenen Systeme gedacht sind, um sie programmatisch zu konsumieren – ein anderer Mechanismus als Benachrichtigungsregeln, den es sich lohnt, getrennt zu kennen, da beide benachbarte, aber unterschiedliche Probleme lösen (einen Menschen alarmieren vs. ein System integrieren).
Was ehrlicherweise noch Beta ist
E-Mail-Zustellung hängt davon ab, dass E-Mail-Versand auf Railyards eigener Seite konfiguriert ist, und ist genau deswegen als Beta markiert – alles, worauf man sich tatsächlich verlässt, sollte zusätzlich eine Slack- oder Webhook-Regel als zweiten Kanal haben, nicht nur E-Mail. Jede Regel hat ein Ziel; zwei Slack-Kanäle bedeuten zwei Regeln, nicht eine Regel mit zwei Zielen. Beides sind kleine, konkrete Grenzen, klar benannt, statt an dem Tag entdeckt zu werden, an dem ein E-Mail-Alarm stillschweigend nicht angekommen ist.
Vollständige Referenz: Benachrichtigungen.