Ein Deployment scheitert, ein Pod bleibt krank, ein Zertifikat läuft ab, ein Upgrade steht an: Clusterward meldet es per Webhook, Slack, Teams oder E-Mail. Einmal pro Ereignis, mit Entwarnung.
Benachrichtigungen sind Kanäle pro Workspace, die ausgewählte Ereignisse aus dem Betrieb erhalten: ein Webhook mit JSON-Umschlag oder Slack- und Teams-Format, oder eine E-Mail-Adresse. Ereignisquellen sind Deployments, Onboarding-Läufe, Importe, Add-on-Installationen sowie zwei Wächter: einer beobachtet Pods pro Cluster und meldet nur Übergänge, einer prüft täglich Zertifikate. Jede Benachrichtigung landet in einer Warteschlange, wird mit Wiederholung zugestellt, mit HMAC signiert und ohne Geheimnisse gebaut.
Ein Deployment, ein Lauf, ein Wächter erzeugt genau eine Nachricht pro Kanal und Ereignis.
Der Inhalt entsteht aus einer Whitelist von Feldern; Fehlertexte werden von Zugangsdaten bereinigt.
Die Nachricht wartet als Zeile, unabhängig davon, was sie ausgelöst hat.
Webhook oder SMTP, signiert, mit Backoff von Sekunden bis Minuten.
Letzte Zustellung und letzter Fehler stehen am Kanal.
Nicht die Menge der Alarme entscheidet, sondern ob jeder einzelne eine Handlung bedeutet.
Dorthin, wo Ihr Team ohnehin liest – mit dem Weg zur Ursache.
Ein Webhook erhält einen JSON-Umschlag; Slack- und Teams-URLs werden erkannt und bekommen eine Textnachricht. Nur https, mit Signatur bei gesetztem Secret.
Zustellung über den SMTP-Server der Plattform an eine beliebige Adresse, ohne eigene Mail-Infrastruktur.
E-Mails kommen mit Logo, farbiger Statuszeile, den Details als Tabelle und einem Knopf zur richtigen Seite, auch im dunklen Modus des Mailprogramms. Absender, Betreff und Fußzeile nennen die Domain Ihres Workspaces und die Firmenangaben des Betreibers – eine Textfassung ist immer dabei.
Die Nachricht zu einem gescheiterten Deployment verlinkt die Logs des Services, bei einem Absturz den vorherigen Lauf.
Pods, Seiten, Zertifikate und Versionen – gemeldet, wenn es zählt.
Ein Pod gilt erst als auffällig, wenn er in zwei Schnappschüssen hintereinander erscheint. Eine Nachricht pro Episode, eine Entwarnung, wenn er sich erholt.
Uptime-Checks prüfen die Domains eines Services von außen. Nach zwei Fehlschlägen in Folge kommt eine Nachricht, nach dem ersten Erfolg die Entwarnung.
Täglich und kurz nach dem Start: verwaltete Wildcards werden aufgefrischt, jedes Zertifikat mit weniger als 14 Tagen oder ohne Ready-Status gemeldet, einmal pro Tag.
Neue Kubernetes-Versionen und Add-on-Versionen aus dem Katalog erscheinen einmal pro Version, nicht bei jedem Lauf.
Auffällige Anmeldungen und Rotationen, ohne selbst Geheimnisse zu verraten.
Admins erfahren, wenn eine Adresse nach zu vielen Fehlversuchen gesperrt oder ein Konto gesperrt wurde. Nutzer bekommen eine E-Mail bei einer Anmeldung von einer neuen Adresse.
Eine neue Version im Secret Manager meldet sich, ein gelöschtes Secret einmal – bevor der nächste Deploy daran scheitert.
Inhalte werden aus Whitelists gebaut, Fehlertexte bereinigt, und eine Nachricht mit geheim aussehendem Feld wird verworfen statt gesendet.
Eine Zeile pro Kanal und Ereignis; das Erzeugen kann nie ein Deployment scheitern lassen.
Wiederholung von Sekunden bis Minuten, dauerhafte Ablehnung endet sofort.
X-Operator-Signature über den Body, prüfbar auf Ihrer Seite.
Plattformweiter Mailversand ohne Cloud-SDK.
Jeder Kanal abonniert seine eigene Auswahl. Ein Slack-Kanal für Deployments, eine E-Mail für Zertifikate.
| Ereignis | Quelle | Bedeutung |
|---|---|---|
| deployment.failed / healthy | Deployments | Rollout gescheitert oder gesund |
| onboarding.failed / succeeded | Tenant-Pipelines | Onboarding-Lauf gescheitert oder fertig |
| import.failed | Datenbank- und Bucket-Import | Ein Import ist gescheitert |
| pods.attention / recovered | Pod-Wächter | Pods auffällig bzw. wieder gesund |
| certificate.expiring | Zertifikatswächter | Weniger als 14 Tage oder nicht bereit |
| addon.failed / upgraded / upgrade_available | Add-ons | Installation gescheitert, Upgrade erfolgt, neue Version im Katalog |
| volume.snapshot.failed | Volumes | Ein geplanter Snapshot ist gescheitert |
| cluster.upgrade_available / finished / failed | Cluster-Updates | Neue Kubernetes-Version, Upgrade beendet oder gescheitert |
| secret.rotated / secret.missing | Secrets | Neue Version im Secret Manager oder Secret gelöscht |
| auth.ip_blocked / auth.account_locked | Anmeldung | Adresse nach Fehlversuchen gesperrt oder Konto gesperrt |
| uptime.down / recovered | Uptime-Checks | Seite nicht erreichbar bzw. wieder erreichbar |
Die meisten Ereignisse stammen aus Deployments und Tenant-Pipelines; der Zertifikatswächter gehört zu DNS und Zertifikaten.
Welche Nutzer Kanäle anlegen dürfen, regelt die Rolle im Bereich Nutzer, beschrieben unter Sicherheit und Zugriff.
Uptime-Checks, Auslastung und Logs am Service beschreibt Logs & Monitoring.
Git, Container-Image oder Helm-Chart – mit Health-Check ausgerollt.
Zu DeploymentsKubernetes-Version, Node-Pools und Add-ons aus dem Cockpit.
Zu Cluster-UpdatesCloudflare-Zonen, Records automatisch, Wildcard-Zertifikate verwaltet.
Zu DNS & ZertifikateIhre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.
Frage stellenWir verbinden Ihren Slack- oder Teams-Kanal, senden eine Testnachricht und lösen ein echtes Deployment-Ereignis aus.
