obhutDoku

Dokumentation durchsuchen

Dokumentationsseiten durchsuchen

Verfügbarkeitschecks einrichten

Eine öffentliche HTTPS-Verfügbarkeitsprüfung je Anwendung aktivieren, Zustandswechsel lesen und den Verlauf als Nachweis exportieren.

obhut prüft alle fünf Minuten genau einen öffentlichen HTTPS-Pfad Ihrer Anwendung und benachrichtigt verifizierte Eigentümer und Admins per E-Mail, wenn er ausfällt und wenn er sich wieder erholt.

Aktivieren

Es gibt höchstens eine Prüfung je Anwendung und höchstens 20 je Organisation. Legen Sie sie im Dashboard an der Anwendung an oder per API (Rolle admin):

curl --fail-with-body -X POST \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/uptime-check" \
  --header "Authorization: Bearer $OBHUT_PAT" \
  --header 'Content-Type: application/json' \
  --data '{"path": "/healthz", "enabled": true}'

Der Pfad ist root-relativ (beginnt mit /), ohne Query und ohne Fragment. Der Hostname ist immer der Ihrer Anwendung — ein fremdes Ziel ist nicht möglich. Ändern Sie den Pfad später, wird der bisherige Verlauf verworfen, weil er sich auf ein anderes Ziel bezog.

Feste Regeln

Diese Werte sind bewusst nicht konfigurierbar:

RegelWert
Intervallalle 5 Minuten
Zeitlimit5 Sekunden
Schwelle für „nicht erreichbar"2 aufeinanderfolgende Fehler
Erreichbarjede Antwort mit Status < 500
Weiterleitungenwerden nicht verfolgt
Aufbewahrung des Verlaufs90 Tage

Ein Fehlschlag wird auf genau eine von zwei Arten festgehalten:

  • Ihre Anwendung hat geantwortet, aber mit 500 oder höher. Der Grund steht im statusCode; errorCode bleibt leer.
  • Es kam gar keine HTTP-Antwort zustande. Dann bleibt statusCode leer und errorCode trägt genau einen dieser Gründe: invalid_target, dns_failed, tls_failed, timeout oder connection_failed.

Ein leeres errorCode-Feld in einem down-Eintrag ist also kein Fehler, sondern der Normalfall bei einer 5xx-Antwort. Rohfehler, Antwortinhalte und IP-Adressen werden nie gespeichert.

Benachrichtigungen

Nach zwei aufeinanderfolgenden Fehlern meldet obhut den Ausfall, bei der Erholung die Rückkehr — jeweils einmal. Empfänger sind ausschließlich verifizierte direkte Eigentümer und Admins Ihrer Organisation.

Zustand und Verlauf lesen

Die Leseroute liegt hinter dem security_reader-Gate:

curl --fail-with-body \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/uptime-check" \
  --header "Authorization: Bearer $OBHUT_PAT"

Sie erhalten den aktuellen Zustand plus die neuesten 50 Zustandswechsel. Gespeichert werden nur Wechsel, kein Eintrag je Prüfung. Eine neue Prüfung startet im Zustand unknown, daher erzeugt schon die erste erfolgreiche Prüfung einen Eintrag (unknownup): eine dauerhaft erreichbare Anwendung hat genau diesen einen Eintrag, nicht null. Erst ein Ausfall und die Erholung erzeugen weitere.

Den vollständigen 90-Tage-Verlauf blättern Sie seitenweise:

curl --fail-with-body \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/uptime-check/events?limit=50" \
  --header "Authorization: Bearer $OBHUT_PAT"

Die Antwort liefert events und einen nextCursor. Rufen Sie erneut mit ?cursor=<nextCursor> auf, bis nextCursor null ist.

Verlauf exportieren

curl --fail-with-body \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/uptime-check/events/export?format=csv" \
  --header "Authorization: Bearer $OBHUT_PAT" \
  --output uptime-events.csv

Die Kopfzeile der CSV-Datei:

id,status,observedAt,statusCode,latencyMs,errorCode

Mit format=json erhalten Sie dieselben Einträge als JSON.

Sofort prüfen

Ein manueller Lauf ist möglich, aber serverseitig gedrosselt: nach einem Lauf antwortet die Route 30 Sekunden lang mit 429 und retry_later.

curl --fail-with-body -X POST \
  "https://api.obhut.io/tenants/$TENANT/resources/$RESOURCE_ID/uptime-check/run" \
  --header "Authorization: Bearer $OBHUT_PAT"

Pausieren ({"enabled": false}) hält die Prüfung an, ohne die Konfiguration zu verlieren. DELETE auf dieselbe Route entfernt Prüfung und Verlauf endgültig.