HTTP/HTTPS

Überblick

Der HTTP/HTTPS-Monitor prüft die Verfügbarkeit eines Webdienstes, indem er eine HTTP-Anfrage an die angegebene URL sendet und die Antwort auswertet. Es ist der am häufigsten verwendete Monitor-Typ.

Grundeinstellungen

Einstellung	Beschreibung	Standard
URL	Vollständige Adresse des Dienstes (https://...)	—
Methode	GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS	GET
Intervall	Prüffrequenz	kürzestes Ihres Tarifs
Erwartete(r) Code(s)	HTTP-Statuscode(s), die als Erfolg gelten, z. B. 200 oder ein Bereich 200-299	200-299
Regionen	Prüfstandorte	eine, die günstigste Ihres Tarifs
Wiederholungen	Aufeinanderfolgende Fehlschläge, die toleriert werden, bevor der Monitor als down gilt	1 (also 2 Fehlschläge)

Jede Prüfung hat ein festes 5-Sekunden-Budget — Verbindung, Antwort und, bei HTTPS, das Lesen des Zertifikats finden darin statt. Es gibt keine Zeitbudget- Einstellung je Monitor; ein Ziel, das binnen 5 s nicht geantwortet hat, gilt als fehlgeschlagene Prüfung.

Erweiterte Einstellungen

Authentifizierung

Ein geschützter Endpunkt hat einen eigenen Block: Basic Auth, Bearer-Token, API-Schlüssel (Header oder URL-Parameter), Sitzungscookie, OAuth2 Client Credentials oder ein Client-Zertifikat (mTLS). Jedes Geheimnis ist im Ruhezustand verschlüsselt und beim Lesen maskiert — siehe Authentifizierung.

Eigene Header

Fügen Sie jeder Prüfanfrage HTTP-Header hinzu, zusätzlich zum (oder anstelle des) Authentifizierungsblocks:

X-Tenant: acme
Content-Type: application/json
Accept: application/json

Anfrage-Body

Für POST oder PUT definieren Sie einen JSON-Body, der bei jeder Prüfung mitgesendet wird:

{
  "health": true
}

Anwendungsfall: prüfen, ob ein API-Endpunkt korrekt auf eine POST-Anfrage antwortet (z. B. ein Health-Endpunkt, der einen bestimmten Body erwartet).

Inhaltsprüfung: Schlüsselwort oder JSON-Abfrage

Über den Statuscode hinaus kann ein HTTP-Monitor den Inhalt der Antwort prüfen. Im Anlegedialog (Schritt 1, direkt unter der URL) und in der Bearbeitungsansicht bietet die Auswahl Inhaltsprüfung drei Modi:

Modus	Was er tut
Nur Statuscode	Standard — es werden nur die akzeptierten Statuscodes geprüft.
Schlüsselwort	Die Prüfung schlägt fehl, wenn der Text nicht im Antwort-Body vorkommt (oder, invertiert, wenn er vorkommt).
JSON-Abfrage	Die Antwort wird als JSON gelesen, ein Pfad aufgelöst und mit einem erwarteten Wert verglichen.

Schlüsselwort und JSON-Abfrage schließen einander aus: Ein Monitor nutzt das eine oder das andere. Die Schaltfläche Testen wertet die Inhaltsprüfung zusammen mit Statuscode, Methode, Headern und Zugangsdaten aus, das angezeigte Ergebnis entspricht also genau dem, was die echten Prüfungen liefern werden — eine fehlgeschlagene Inhaltsprüfung nennt den Grund (z. B. Keyword 'operational' not found in response body).

Schlüsselwort

Feld	Beschreibung
Schlüsselwort	Text, der im rohen Antwort-Body gesucht wird — reines HTML oder JSON. Groß-/Kleinschreibung zählt.
Muss fehlen	Invertiert die Prüfung: Sie schlägt fehl, wenn das Schlüsselwort gefunden wird (Wartungsseite mit Status 200).

Beispiele:

• Prüfen, ob Ihre Startseite Willkommen enthält (und nicht eine mit 200 ausgelieferte Fehlerseite).
• Prüfen, ob eine API "status":"operational" zurückgibt.
• Wartungsseiten erkennen, die mit Statuscode 200 ausgeliefert werden.

Wann eine Schlüsselwortprüfung?

Ein Server kann eine 200 zurückgeben und dabei eine Fehlerseite ausliefern (Load Balancer, CDN, Wartungsseite). Eine Schlüsselwortprüfung fängt diese Fehlalarme ab, die der Statuscode allein nicht erkennt.

JSON-Abfrage

Feld	Beschreibung
JSON-Pfad	Punktnotation ab der Wurzel des Dokuments: component.status, data.items.0.name. Ein führendes $. wird akzeptiert. $ allein steht für den rohen Body.
Operator	==, !=, contains, >, <, >=, <=
Erwarteter Wert	Wird mit dem aufgelösten Wert als Zeichenfolge verglichen (Zahlen und Wahrheitswerte werden in Text umgewandelt: true, 42). Numerische Operatoren lesen beide Seiten als Zahlen.

Die Prüfung schlägt fehl, wenn der Body kein gültiges JSON ist, wenn der Pfad nicht auflöst oder wenn der Vergleich falsch ist. $ überspringt das JSON-Parsen und vergleicht den gesamten (getrimmten) Antwort-Body — praktisch für Health-Endpunkte im Klartext, die OK oder pong antworten.

Beispiel — ein Statuspage-Komponentenendpunkt wie https://public-cloud.status-ovhcloud.com/api/v2/components/8x32jhcpqq1m.json liefert:

{ "page": { "...": "..." }, "component": { "name": "GRA1", "status": "operational" } }

JSON-Pfad	Operator	Erwarteter Wert	Ergebnis
component.status	==	operational	✅ besteht
component.status	!=	operational	❌ schlägt fehl, sobald die Komponente beeinträchtigt/down ist
$	contains	"status":"operational"	✅ besteht (roher Body)

SSL-/TLS-Zertifikat

Bei einem https://-Ziel liest OKStatus bei jeder Prüfung das Zertifikat und erfasst die verbleibenden Tage bis zum Ablauf.

• Ein abgelaufenes oder anderweitig ungültiges Zertifikat lässt die Prüfung fehlschlagen.
• Ablaufalarme feuern ab dem Tarif Pro, 30, 14, 7, 3 und 1 Tag vor Ablauf des Zertifikats — ein Alarm je Schwelle, nicht einer je Prüfung. Der Ablauf der Domainregistrierung wird genauso überwacht, bei 60, 30, 14 und 7 Tagen.
• Beide sind eigene Alarmarten, ein Kanal kann also Ausfallalarme erhalten, ohne die zum Zertifikat (oder umgekehrt).

Aktivieren Sie am Monitor TLS-Zertifikatsprüfung überspringen, um ein selbst signiertes oder abgelaufenes Zertifikat zu akzeptieren — etwa für eine Staging-Umgebung, die Sie bewusst so betreiben.

Weiterleitungen

Ein Monitor folgt Weiterleitungen standardmäßig, bis zu 5 Sprünge, und jeder Sprung wird gegen dieselben Sicherheitsregeln geprüft wie die ursprüngliche URL. Klassifiziert wird der Statuscode am Ende der Kette.

Schalten Sie Weiterleitungen folgen aus, um die URL exakt so zu prüfen, wie Sie sie eingegeben haben. Der Monitor fragt dann zusätzlich, wie eine 3xx zu behandeln ist, die nicht in Ihren akzeptierten Codes steht:

Einstellung für eine 3xx	Ergebnis
Beeinträchtigt (Standard)	Der Server hat geantwortet — das ist eine Konfigurationsabweichung, kein Ausfall. Bernstein, kein Weckruf.
Down	Streng: Jede unerwartete Weiterleitung gilt als Ausfall.

4xx, 5xx und nicht erreichbare Ziele sind nach Ablauf des Wiederholungsfensters immer down, unabhängig von dieser Einstellung. Soll die Weiterleitung selbst als Erfolg zählen, nehmen Sie stattdessen ihren Code (z. B. 301) in die akzeptierten Statuscodes auf — die Schaltfläche Testen bietet genau das an, wenn sie auf eine trifft.

Erfasste Messwerte

Jede HTTP-Prüfung erfasst:

Messwert	Beschreibung
Status	up, beeinträchtigt oder down
HTTP-Code	Antwortcode (200, 404, 503 …)
Latenz	Gesamte Antwortzeit in ms
Region	Region, aus der die Prüfung lief