Website-Überwachung mit Webhooks
Uptimia prüft Ihre Websites, Zertifikate und Checkout-Abläufe von außerhalb Ihres Netzwerks und ruft Ihren Endpunkt bei jedem bestätigten Ausfall auf. Ihr eigener Code entscheidet, was danach geschieht — ein Ticket öffnen, einen Dienst neu starten, ein Dashboard füttern — und jede Prüfung sendet dasselbe Format, sodass Sie den Handler nur einmal schreiben.
Authorization: Bearer •••••••••••••••• Content-Type: application/json { "id": 3517, "monitor_type": "uptime", "monitor_name": "Checkout — caldmont.com", "monitor_unique_id": "checkout-prod", "monitor_status": "down", "severity": "critical", "incident_start_time": "2026-07-30T11:47:12+02:00", "incident_end_time": "", "incident_duration_seconds": 0, "message": "*ALERT*: Project Checkout — caldmont.com is DOWN", "monitor_notes": "Failover: drain eu-west-2 first" }
Keine Nachricht, ein Vertrag
Jeder andere Kanal endet bei einer Person, und Personen sind nachsichtige Leser. Code ist das nicht — deshalb ist das Interessante nie die Payload, sondern die Garantien dahinter.
„Da ist etwas kaputtgegangen“ — den Rest klären Sie selbst
Formulierungen dürfen zwischen Releases driften, weil sich der Leser anpasst. Sobald Software davon abhängt, wird diese Unverbindlichkeit zum Fehler in Ihrer Integration.
Elf Felder, fünf Wiederholungen, ein Format
Ein Objekt für jede Art von Prüfung: einen Handler schreiben, an zwei Feldern verzweigen. Vor dem Verwerfen wird bis zu fünfmal wiederholt — Duplikate sind also möglich, dokumentiert statt entdeckt.
Die Warnung landet in Ihrem eigenen Code
Eine Prüfung schlägt fehl, und Uptimia ruft Ihren Endpunkt mit den Details auf — bereits bestätigt. Ihre eigene Automatisierung entscheidet, was weiter geschieht — hier ein Ticket, das sich selbst öffnet und bei Wiederherstellung schließt.
Webhook in drei Schritten anbinden
Keine App zu autorisieren, keine Bibliothek zu installieren — Uptimia braucht eine URL zum Aufrufen und, falls der Endpunkt geschützt ist, einen Header, der hineinlässt.
URL Ihres Endpunkts einfügen
Das ist die gesamte Registrierung — eine öffentliche URL.
Ihre Auth-Header ergänzen
Optional — Header werden exakt so gesendet, wie Sie sie schreiben; ein Token lässt Uptimia also durch Ihre eigene Tür.
Ihre Monitore darauf richten
Wählen Sie die Prüfungen aus, die ihn aufrufen sollen — eine Testzustellung beweist die Anbindung mit dem echten Format.
Einen Webhook-Endpunkt registrieren
Das Hilfecenter behandelt die Umsetzung: die URL hinzufügen, eigene Header schreiben, einen Test-POST senden und lesen, was eine fehlgeschlagene Zustellung Ihnen sagt.
Jede Art von Prüfung. Ein Format.
Ein ablaufendes Zertifikat, ein Cron-Job, der sich nie gemeldet hat, und ein Server über seinem CPU-Grenzwert kommen alle als dasselbe flache Objekt an. Zwei Felder unterscheiden sie.
Chat-Bridges, Datenbankzeilen, automatisierte Aktionen
Sobald ein Vorfall ein Objekt ist, das Ihr Code angenommen hat, sieht die nützliche Anwendung nicht mehr nach Alarmierung aus.
Andere Kanäle informieren eine Person.Dieser informiert Ihren Code.
Die komplette Plattform im Test — jede Art von Prüfung, 171+ Prüfstandorte und jeder bestätigte Vorfall als Objekt zugestellt, das Ihnen gehört.
Die Zustellungsgarantien, schwarz auf weiß
Auf „Wir schicken Ihnen eine Benachrichtigung“ lässt sich kein verlässlicher Handler bauen. Dies sind die tatsächlichen Garantien.
At-Least-Once, mit fünf Wiederholungen
Zehn Sekunden für die Antwort, und jedes 2xx gilt als angenommen. Alles andere wird erneut eingereiht und fünfmal wiederholt, wobei die Wartezeit jedes Mal eine Minute länger wird, dann verworfen — antworten Sie also zuerst und erledigen Sie die Arbeit danach.
Ein flaches Objekt, elf Schlüssel
Keine Verschachtelung, kein Wrapper-Objekt, kein Schema, das sich mit dem Prüfungstyp ändert. Zwei Felder unterscheiden sie; die anderen neun ändern ihre Bedeutung nie — darunter monitor_notes, die Runbook-Zeile von der Person, die den Monitor eingerichtet hat.
Sturm ergänzt einen Schlüssel
Gemeinsam ausfallende Monitore werden zu einer Anfrage mit zusätzlichem Gruppenobjekt — Mitglieder, Zähler, Quittierung. Handler, die es ignorieren, funktionieren weiter.
Ihre Header, unverändert durchgereicht
Wortgleich gesendet — funktioniert also ein Bearer-Token oder Shared Secret. Es gibt keine Body-Signatur: Prüfen Sie den Header serverseitig und halten Sie die URL geheim.
Wohin Uptimia nicht postet
Nur öffentliches http(s); Loopback und private Bereiche werden abgelehnt. Die Adresse wird einmal aufgelöst und fixiert, Weiterleitungen ignoriert, TLS geprüft.
Kein Quittierungslink — mit Absicht
Kanäle, die eine Person liest, tragen einen signierten Link, der die Eskalationsleiter stoppt. Maschinen bekommen nur die Fakten — eine Log-Pipeline, die einen Pager stummschalten kann, wird es irgendwann auch tun.
So funktionieren Monitoring-Webhooks
Uptimia prüft Ihre Websites von 171+ externen Standorten und sendet bei einer fehlgeschlagenen Prüfung ein HTTP-POST mit JSON-Body an jede URL, die Sie registrieren. Dasselbe flache Objekt kommt für jede Art von Prüfung an — welcher Monitor, was passiert ist, wann und wie lange — sodass ein Handler alle abdeckt, und fehlgeschlagene Zustellungen werden wiederholt.
Der Bug, den alle am ersten Tag einbauen
Wiederherstellungen, Warnungen und Tests teilen sich einen Endpunkt. monitor_status ist down, up oder test; severity ist critical oder trouble und bei einer Wiederherstellung leer. Prüfen Sie beide Felder.
Bestätigt, bevor Ihr Code davon erfährt
Automatisierung ist nur so vertrauenswürdig wie ihr Auslöser. Eine Web-Prüfung löst nie wegen der Einschätzung eines einzelnen Prüfstandorts eine Warnung aus — ein vermuteter Ausfall wird zuerst von anderen Prüfknoten nachgetestet.
Elf Felder, jedes Ereignis
Was immer vorhanden ist und was es enthält.
Alle Benachrichtigungskanäle ansehen →| Feld | Beispiel | Inhalt |
|---|---|---|
| id | 4172 | Die numerische ID des Monitors in Uptimia |
| monitor_type | uptime | Welche Art von Prüfung ausgelöst hat |
| monitor_name | Dispatch API | Der Name, den Sie ihm gegeben haben (Websitename bei Verfügbarkeitsprüfungen) |
| monitor_unique_id | dispatch-api-eu | Ihr eigener Bezeichner — der Join-Schlüssel |
| monitor_status | down | down, up oder test |
| severity | critical | critical oder trouble — bei einer Wiederherstellung leer |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, Zeitzone des Kontos |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Leer, solange der Vorfall offen ist |
| incident_duration_seconds | 843 | Null, bis der Vorfall geschlossen wird |
| message | *ALERT*: Project … is DOWN | Die einzeilige Zusammenfassung, die andere Kanäle erhalten |
| monitor_notes | Failover: drain eu-west-2 first | Die Notiz des Monitors — leer, wenn niemand eine geschrieben hat |
FAQ zu eigenen Webhooks
01Was genau senden Sie?+
02Wie authentifiziere ich die Anfrage?+
03Was passiert, wenn mein Endpunkt langsam oder down ist?+
04Bekomme ich dasselbe Ereignis manchmal doppelt?+
05Kann ich ihn auf localhost oder eine interne Adresse zeigen lassen?+
06Folgen Sie Weiterleitungen?+
07Was kommt an, wenn mehrere Monitore gleichzeitig ausfallen?+
08Kann mein Handler bestätigen oder antworten?+
09Was postet „Test senden“ tatsächlich?+
10Wie viele Endpunkte kann ich haben, und ist das inbegriffen?+
Eine URL, jeder bestätigte Vorfall
Registrieren Sie einen Endpunkt, verknüpfen Sie ihn mit den Monitoren, die zählen, und jeder bestätigte Ausfall kommt als Objekt an, das Ihre Systeme ablegen und verarbeiten können.