Dokumentation / Monitoring und Sicherheit
Benachrichtigungen
Werde bei Ausfällen, Serverproblemen und Dienstereignissen per Slack, Teams oder Webhooks benachrichtigt.
calmo.cloud kann Echtzeit-Benachrichtigungen an dein Team senden, wenn etwas Aufmerksamkeit erfordert — ob eine Seite ausfällt, eine Server-Metrik einen Schwellenwert überschreitet oder ein Odoo-Dienst seinen Status ändert.
Unterstützte Ziele #
| Typ | Beschreibung |
|---|---|
| Slack | Sendet formatierte Nachrichten mit farbiger Statusleiste und Aktionsbuttons an einen Slack-Kanal |
| Microsoft Teams | Sendet Adaptive-Card-Nachrichten an einen Teams-Kanal |
| Webhook | Sendet signierte JSON-Daten an eine beliebige https://-URL — siehe Webhook-Daten |
Ein Ziel einrichten #
1. Zu Benachrichtigungsziele gehen #
Navigiere zu Einstellungen > Benachrichtigungsziele und klicke auf Neues Ziel.
2. Ziel konfigurieren #
Gib an:
- Name — Ein aussagekräftiger Name (z.B. „Ops Slack-Kanal")
- Typ — Slack, Teams oder Webhook
- Webhook-URL — Die Incoming-Webhook-URL deiner Messaging-Plattform oder die Adresse deines eigenen Endpunkts. Sie muss mit
https://beginnen und aus dem Internet erreichbar sein (siehe Gesperrte Adressen).
Erstelle für Slack einen Incoming Webhook in den Slack-Workspace-Einstellungen unter Apps > Incoming Webhooks.
3. Verbindung testen #
Klicke nach dem Speichern auf Send Test auf der Bearbeitungsseite des Ziels. Die Testnachricht geht sofort raus, und du siehst direkt, was passiert ist: mit welchem HTTP-Status dein Endpunkt geantwortet hat und wie lange das gedauert hat — oder warum die Zustellung gescheitert ist. Pro Ziel sind fünf Tests pro Minute möglich. Jeder Test erscheint wie jede andere Zustellung unter Logs.
Ereignis-Abonnements #
Jedes Ziel kann bestimmte Ereignistypen abonnieren. Gehe zum Bereich Abonnements auf der Bearbeitungsseite eines Ziels, um zu konfigurieren, welche Ereignisse Benachrichtigungen auslösen. Mit Add Subscriptions wählst du mehrere Ereignisse auf einmal aus.
Verfügbare Ereignisse #
| Kategorie | Ereignis | Beschreibung |
|---|---|---|
| Verfügbarkeit & Zertifikate | Verfügbarkeitsprüfung fehlgeschlagen | Eine überwachte URL antwortet nicht |
| Verfügbarkeitsprüfung wiederhergestellt | Eine zuvor ausgefallene URL ist wieder erreichbar | |
| Zertifikatsprüfung fehlgeschlagen | Ein SSL-Zertifikat ist ungültig | |
| Zertifikat läuft bald ab | Ein SSL-Zertifikat läuft bald ab | |
| Server-Metriken | CPU-Auslastung hoch | Die CPU-Auslastung hat den Schwellenwert überschritten |
| Speicherauslastung hoch | Die Speicherauslastung hat den Schwellenwert überschritten | |
| Festplattenauslastung hoch | Die Festplattenauslastung hat den Schwellenwert überschritten | |
| Server-Ereignisse | Server eingeschaltet | Ein Server wurde eingeschaltet |
| Server ausgeschaltet | Ein Server wurde ausgeschaltet | |
| Odoo-Ereignisse | Odoo-Dienst gestoppt | Ein Odoo-Dienst wurde gestoppt |
| Odoo-Dienst neu deployt | Ein Odoo-Dienst wurde neu deployt |
Metrik-Schwellenwerte #
Für Server-Metrik-Ereignisse (CPU, Speicher, Festplatte) kannst du einen eigenen Schwellenwert in Prozent (1–100%) festlegen. Der Standard-Schwellenwert liegt bei 90%. Benachrichtigungen werden gesendet, wenn der aktuelle Wert deinen konfigurierten Schwellenwert überschreitet.
Coding-Agenten #
Ereignisse von Coding-Agenten gehen nicht an Benachrichtigungsziele. Soll dein eigenes System erfahren, wenn ein Agent eine Entscheidung braucht, seinen Durchgang beendet oder einen Pull Request öffnet, leg auf der Seite Webhook einen Webhook mit der Quelle Agent sessions an — siehe Webhooks.
Wer eine Sitzung im Panel gestartet hat, bekommt über die Glocke im Panel Bescheid, wenn der Agent eine Entscheidung oder eine Antwort braucht und wenn die Sitzung fehlschlägt oder nicht starten kann. Dafür ist weder ein Ziel noch ein Webhook nötig. Bei Sitzungen, die über die API gestartet wurden, gibt es niemanden, dem das Panel Bescheid geben könnte.
Slack-Nachrichtenformat #
Slack-Benachrichtigungen enthalten:
- Eine farbige Seitenleiste, die den Schweregrad anzeigt (rot bei Ausfällen, grün bei Wiederherstellungen, orange bei Warnungen)
- Eine Überschrift mit dem Ereignistitel
- Details zur betroffenen Ressource
- Einen Details anzeigen-Button mit Direktlink zur Ressource in calmo.cloud
- Einen Zeitstempel in der Fußzeile
Webhook-Daten #
Ein Ziel vom Typ Webhook bekommt jede Benachrichtigung als POST mit JSON-Body und diesen Headern:
| Header | Inhalt |
|---|---|
content-type |
application/json |
user-agent |
calmo.cloud-Webhooks/1 |
calmo-event-type |
Der Ereignistyp, derselbe wie event_type im Body |
webhook-id |
Die ID der Benachrichtigung, dieselbe wie id im Body. Sie bleibt bei jeder Wiederholung gleich. |
webhook-timestamp |
Wann dieser Versuch verschickt wurde, in Unix-Sekunden |
webhook-signature |
Die Signatur — siehe Webhook-Signaturen |
Der Body enthält diese Schlüssel:
| Schlüssel | Inhalt |
|---|---|
title |
Eine kurze Überschrift |
body |
Ein oder zwei Sätze |
event_type |
Das Ereignis, z. B. odoo_service_stopped. Send Test verwendet test. |
url |
Wo du es dir im Panel ansehen kannst, oder null |
metadata |
Ein paar Fakten als Strings; welche Schlüssel es gibt, hängt vom Ereignis ab |
id |
Eindeutige ID der Benachrichtigung. Daran erkennst du Wiederholungen. |
version |
Version des Body-Formats, derzeit 1 |
occurred_at |
Wann die Benachrichtigung ausgelöst wurde, ISO 8601 in UTC mit Mikrosekunden |
So sieht es zum Beispiel aus, wenn ein Odoo-Dienst stoppt:
{
"title": "Odoo service ACME Live stopped",
"body": "Odoo service ACME Live on prod-1 was stopped.",
"event_type": "odoo_service_stopped",
"url": "https://calmo.cloud/admin/acme/service-odoos/42/edit",
"metadata": {
"service": "ACME Live",
"server": "prod-1"
},
"id": "5f1c9a3e-2b7d-4e8f-a1c6-9d0b3e4f5a27",
"version": 1,
"occurred_at": "2026-09-25T09:41:07.318204Z"
}
title und body sind derzeit immer auf Englisch. Neue Schlüssel können jederzeit dazukommen — ignoriere die, die du nicht kennst.
Webhook-Signaturen #
Jede Anfrage an ein Ziel vom Typ Webhook ist nach der Spezifikation Standard Webhooks signiert. So kann dein Endpunkt prüfen, dass sie wirklich von calmo.cloud kommt und unterwegs nicht verändert wurde. Jedes Webhook-Ziel hat ein eigenes Signing secret, das nach dem Speichern auf seiner Bearbeitungsseite steht (verdeckt, bis du es aufdeckst). Es beginnt mit whsec_.
Zum Prüfen berechnest du den HMAC-SHA256 von {webhook-id}.{webhook-timestamp}.{roher Body} — mit dem Base64-dekodierten Teil des Secrets nach whsec_ als Schlüssel — und vergleichst seine Base64-Kodierung mit dem Wert nach v1, in webhook-signature. Beispiele für PHP und Node.js stehen unter Webhooks; sie funktionieren unverändert mit dem Signing secret eines Ziels. Den dort beschriebenen Header Signature schicken Benachrichtigungsziele nicht.
Ist das Secret in falsche Hände geraten, klicke auf Regenerate signing secret. Ab sofort wird mit dem neuen Secret signiert — trag es also gleich bei deinem Endpunkt ein, sonst lehnt er die Anfragen ab.
Anfragen an Slack und Microsoft Teams werden nicht signiert: Deren Incoming-Webhook-URLs sind geheim und dienen selbst als Zugangsdaten — behandle sie wie ein Passwort.
Zustellung und Wiederholungen #
Eine Benachrichtigung gilt als zugestellt, wenn dein Endpunkt innerhalb von 10 Sekunden mit einem 2xx-Status antwortet. Klappt das nicht, versucht calmo.cloud es erneut: 10 Sekunden nach dem ersten gescheiterten Versuch, danach nach 1 Minute, 5 Minuten und 30 Minuten — insgesamt fünf Versuche über rund 36 Minuten.
Wiederholt wird, wenn der Endpunkt nicht erreichbar ist, sich sein Hostname nicht auflösen lässt, der Verbindungsaufbau oder der TLS-Handshake scheitert, die Anfrage zu lange dauert oder der Endpunkt mit HTTP 408, 425, 429 oder einem 5xx-Status antwortet. Jede andere Antwort beendet die Zustellung sofort:
- Andere 4xx-Status — der Endpunkt hat die Benachrichtigung abgelehnt, und ein erneuter Versuch würde daran nichts ändern
- Weiterleitungen (3xx) — calmo.cloud folgt ihnen nicht; trag stattdessen die endgültige URL ein
- Gesperrte Adressen — siehe unten
Durch Wiederholungen kann dieselbe Benachrichtigung mehr als einmal ankommen, etwa wenn dein Endpunkt sie verarbeitet, aber zu spät geantwortet hat. Webhook-Daten enthalten eine id, die bei jedem Versuch gleich bleibt (sie kommt auch als webhook-id) — daran kann dein Endpunkt Wiederholungen erkennen.
Deaktivierst oder löschst du ein Ziel, während eine Benachrichtigung auf ihren nächsten Versuch wartet, wird sie verworfen.
Gesperrte Adressen #
Benachrichtigungen werden aus dem Netz von calmo.cloud verschickt. Ein Ziel muss deshalb eine öffentliche Adresse im Internet sein. calmo.cloud lehnt ab:
- URLs, die nicht mit
https://beginnen oder einen Benutzernamen oder ein Passwort enthalten - Andere Ports als 443, 8443 oder 1024–65535
localhostund Hostnamen, die auf.localhost,.localoder.internalenden- Hostnamen, die sich beim Speichern des Ziels zu keiner Adresse auflösen lassen
- Hostnamen, von deren Adressen auch nur eine in einem privaten, Loopback-, Link-Local- oder anderen reservierten Bereich liegt
- calmo.cloud selbst und Server, die einem anderen Team gehören (die Server deines eigenen Teams sind erlaubt)
Die URL wird beim Speichern des Ziels geprüft und vor jeder Zustellung erneut, und jede Zustellung geht an genau die Adresse, die geprüft wurde. Eine Zustellung an eine gesperrte Adresse — zum Beispiel bei einem bestehenden Ziel mit einer http://-URL oder einem, dessen Hostname inzwischen in ein privates Netz zeigt — wird nicht wiederholt und steht im Log als blocked, bis du die URL änderst. Lässt sich ein Hostname beim Zustellen nicht auflösen — etwa weil ein DNS-Server nicht geantwortet hat —, ist das keine Sperre: Der Versuch scheitert mit DNS lookup failed und wird wiederholt wie bei einem Endpunkt, der nicht erreichbar ist.
Zustellungs-Log #
Im Bereich Logs eines Ziels steht jeder Zustellversuch: das Ereignis, der Status (success, failed oder blocked), der HTTP-Status, mit dem dein Endpunkt geantwortet hat, die Nummer des Versuchs, die Event-ID und die gesendeten Daten. Bei einem gescheiterten Versuch steht ein kurzer Grund dabei, etwa HTTP 500, Timed out, TLS error, Connection failed, DNS lookup failed oder Redirect not followed.
Was dein Endpunkt zurückschickt, wird nicht gespeichert — nur der HTTP-Status. Log-Einträge werden nach 30 Tagen gelöscht.
Aktivieren und Deaktivieren #
Du kannst Benachrichtigungen auf zwei Ebenen aktivieren oder deaktivieren:
- Ziel-Ebene — Das gesamte Ziel ein- oder ausschalten
- Abonnement-Ebene — Einzelne Ereignis-Abonnements ein- oder ausschalten
Deaktivierte Ziele oder Abonnements erhalten keine Benachrichtigungen. Send Test funktioniert auch bei einem deaktivierten Ziel — so kannst du es prüfen, bevor du es einschaltest.