Wie wir dich informieren oder benachrichtigen
Eine Störung zu erkennen lohnt sich nur, wenn die richtige Person davon erfährt. Wir senden dorthin, wo dein Team bereits hinschaut, und an deine eigenen Systeme, wenn nicht zuerst eine Person reagieren soll.
Die Kanäle
Jeder Kanal erhält die gleiche Nachricht: welcher Monitor, seit wann und warum. Jede Adresse wird einmal hinzugefügt und dann in einer Regel benannt.
-
Email Jeder Tarif
Eine Nachricht an jede Adresse, einmal bestätigt, bevor wir sie senden, damit eine Benachrichtigung nicht an den Posteingang einer anderen Person gerichtet werden kann.
-
Webhook (POST) Jeder Tarif
Ein JSON-Body mit allen unten stehenden Feldern, an eine URL von dir. Für deine eigene Automatisierung: ein Ticket öffnen, eine Schicht benachrichtigen, ein Statuslicht umschalten.
-
Webhook (GET) Jeder Tarif
Die gleichen Felder als Query-Parameter, für einen Empfänger, der nur GET akzeptieren kann.
-
PagerDuty Starter und höher
Ein Vorfall über die Events API v2, eröffnet bei einer Störung und geschlossen bei der Wiederherstellung, sodass PagerDutys eigene Eskalation übernimmt. Ein langsamer oder verlustbehafteter Check wird als Warnung gemeldet, nicht als kritisch.
-
Slack Pro und Business
Eine Nachricht in einem Kanal, rot für offline und grün für wieder online, über einen Webhook.
-
Microsoft Teams Pro und Business
Die gleiche Nachricht in einem Teams-Kanal, über einen Webhook.
-
Discord Pro und Business
Die gleiche Nachricht in einem Discord-Kanal, über einen Kanal-Webhook.
-
Telegram Pro und Business
Die gleiche Nachricht in einem Chat, über deinen eigenen Bot.
Wer erfährt was, und wann
Zuerst bestätigt
Nichts wird auf die Aussage einer einzelnen Probe hin gesendet. Ein Fehler wird zu einer Störung, wenn Proben auf zwei anderen Kontinenten übereinstimmen, sodass eine Benachrichtigung bedeutet, dass die Seite offline ist und nicht ein Netzwerk dazwischen.
Regeln und Eskalation
Eine Regel legt fest, wer von welchen Monitoren erfährt und wie lange nach Beginn der Störung. Setze die Bereitschaftsplanung in eine Kontaktgruppe mit einer Verzögerung pro Mitglied, und eine Regel wird zu einer Eskalation, die endet, sobald der Monitor sich erholt.
Wieder online, einmal gesagt
Jeder, der über die Störung informiert wurde, wird informiert, wenn sie endet, mit der Dauer. Wir wecken dich nicht, um dir zu sagen, dass die Störung vorbei ist.
Teste es, bevor du es brauchst
Jede Adresse hat einen Button, der einen Test über denselben Weg sendet, den eine echte Benachrichtigung nimmt, so formuliert, dass er nicht mit einer echten Störung verwechselt werden kann.
Der Webhook, für deine eigenen Systeme
Eine Webhook-Adresse ist eine URL von dir. Wir rufen sie auf, wenn eine Störung bestätigt wird, wenn sie behoben ist und wenn du Test drückst. POST sendet die Felder als JSON-Body; GET sendet sie als Query-Parameter. Die URL wird verschlüsselt gespeichert und nie wieder vollständig angezeigt, da jeder, der sie hat, darauf posten kann.
| Feld | Was es enthält |
|---|---|
| reason | down bei bestätigter Störung, recovery wenn sie endet, test wenn jemand den Button gedrückt hat |
| monitor | Der Name des Monitors |
| monitor_id | Seine ID, dieselbe wie in seiner Adresse im Dashboard |
| target | Was es prüft: die URL, den Host oder den Namen |
| type | Die Art der Prüfung, als Kurzname wie https, dns oder ssl_cert |
| cause | Warum es fehlgeschlagen ist, in ein paar Worten, wenn wir es wissen |
| error_class | Dasselbe als Kurzname, auf den ein Programm verzweigen kann, wie timeout, connection oder certificate_expired |
| started | Wann die Störung begann, als Uhrzeit mit ihrer Zeitzone |
| confirmed_at | Wann der Fehler bestätigt wurde |
| confirmed_from | Die Kontinente, die es bestätigt haben, als Liste von Namen. Bis September 2026 war es ein einzelner Name |
| degraded | true, wenn der Monitor langsam ist oder Pakete verliert, statt offline zu sein |
| resolved | Wann es endete, als ISO-8601-Zeitstempel, bei einer Wiederherstellung |
| duration | Wie lange es dauerte, in Worten, bei einer Wiederherstellung |
| incident_id | Die ID des Vorfalls, dieselbe bei der Störung und ihrer Wiederherstellung |
Ein Feld ohne Inhalt ist null im JSON und wird bei einem GET weggelassen. Antworte mit jedem Status unter 400. Alles andere zählt als fehlgeschlagene Zustellung und wird nach 30 Sekunden, 2 Minuten und 10 Minuten erneut versucht, dann aufgegeben: ein Alert, der nicht innerhalb einer Viertelstunde angekommen ist, ist Geschichte, keine Nachricht.