Alarme, die Sie prüfen können
E-Mail, Telegram, Slack, Discord oder ein signierter Webhook, in unter einer Minute, pro Check geroutet — und ein Protokoll jeder Zustellung, einschließlich der bewusst nicht gesendeten.
Kanäle
- E-Mail — was passiert ist, seit wann, welche Prüfregionen es bestätigt haben, und ein Link direkt zum Check.
- Telegram — über einen Bot, den okokumo betreibt; die Einrichtung ist „Verbinden“ drücken und dann „Start“, statt einen eigenen Bot zu registrieren.
- Slack — ein Incoming Webhook, den Sie einfügen, zugestellt als formatierte Blocks, mit Testversand aus der Oberfläche.
- Discord — ein Incoming Webhook, den Sie in Ihrem eigenen Server anlegen (Kanal → Kanal bearbeiten → Integrationen → Webhooks) und genauso einfügen. Alarme kommen als Embed an — rot bei Ausfall, grün bei Erholung, grau bei pausiert — mit Statuswechsel, Zeitpunkt, Grund und Ziel, und der Titel verlinkt zurück zum Check. Nichts zu installieren, kein Bot einzuladen.
- Webhook — signiertes JSON über HTTPS an jeden Endpunkt, mit Backoff wiederholt, mit dokumentiertem Payload. Jede Zustellung trägt eine HMAC-Signatur, damit der Empfänger prüfen kann, dass sie von uns kam.
SMS und Telefonanrufe gibt es nicht. Beides steht auf der Liste dessen, was dieses Produkt nicht tut.
Ein Kanal empfängt nichts, bevor er bestätigt ist
Einen Kanal hinzuzufügen sind zwei Schritte, nicht einer. E-Mail wird validiert, wenn Sie den an diese Adresse gesendeten Link anklicken; Webhook, Slack und Discord werden validiert, sobald eine Testzustellung gelingt. Bis dahin existiert der Kanal, ist aber ausstehend, und ausstehende Kanäle empfangen nichts.
Das ist Absicht, und es lohnt sich zu verstehen statt zu umgehen: so geht ein Alarm nie an ein Ziel, das niemand bestätigt hat — eine vertippte Adresse, ein Webhook, der nie erreichbar war, ein gelöschter Slack-Kanal. Der Preis ist, dass ein Check ausfallen kann, ohne Sie zu wecken, wenn sein einziger Kanal nie bestätigt wurde — genau deshalb existiert das Zustellprotokoll weiter unten und sagt es.
Routing
Kanäle lassen sich an bestimmte Checks hängen oder als Organisations-Standard belassen, der alles abdeckt. So kann die kundenseitige API per Telegram ein Telefon wecken, während ein nächtlicher Batch-Job in einen Slack-Raum schreibt, den um 3 Uhr niemand ansieht.
Ein Vorfall, ein Alarm
Ein Wechsel auf „down“ sendet einmal. Solange der Status unverändert bleibt, benachrichtigt nichts erneut — ein Dienst, der sechs Stunden ausgefallen ist, erzeugt keine sechs Stunden Nachrichten, denn ein Kanal, der falschen Alarm schlägt, wird stummgeschaltet, und ein stummgeschalteter Kanal ist schlimmer als kein Monitoring. Die Erholung sendet ihre eigene Benachrichtigung, damit Schweigen nie interpretiert werden muss.
Darunter muss ein Fehler von einer zweiten unabhängigen EU-Prüfregion bestätigt werden, bevor irgendetwas davon beginnt. So funktioniert das →
Der Teil, den Ihnen sonst niemand zeigt
Jeder Check führt ein Zustellprotokoll: was gesendet wurde, an welchen Kanal, wann — und was übersprungen wurde, mit Grund. Dedupliziert, weil sich der Status nicht geändert hatte. Übersprungen, weil der Kanal noch ausstehend war. Fehlgeschlagen, weil der Endpunkt eine 500 zurückgab.
Jedes Monitoring-Produkt behauptet, es alarmiere Sie. Das hier ist die Behauptung, die man prüfen kann, und der Grund, warum das Protokoll ein Feature ist und keine interne Tabelle.
Über die API
Die Alarme eines Checks sind über die versionierte REST-API mit einem Organisationsschlüssel lesbar, neben Checks, Status und Ergebnissen. Dokumentation →