HTTP/HTTPS-Checks

HTTP/HTTPS-Checks prüfen, ob eine Website oder API erreichbar ist und korrekt antwortet. Der am häufigsten genutzte Check-Typ, in allen Plänen verfügbar.

Was wird geprüft?

LIVCK ruft die URL auf und meldet:

Ob die Seite erreichbar ist
Wie schnell sie antwortet
Ob Statuscode und Inhalt stimmen

Funktioniert für öffentliche Websites genauso wie für interne APIs oder Login-Seiten.

Ziel eingeben

Gib die vollständige URL ein. Sie muss mit http:// oder https:// beginnen.

Beispiele:

https://www.example.com
https://api.example.com/health
http://intranet.example.com:8080/status

HTTPS bevorzugen

Verwende wenn möglich https://. So wird gleichzeitig geprüft, ob die verschlüsselte Verbindung funktioniert.

Konfigurationsoptionen

HTTP-Methode

Methode	Verwendung
GET	Standard. Ruft die Seite ab. Für die meisten Websites und APIs die richtige Wahl.
POST	Sendet Daten an den Server. Nützlich für API-Endpunkte, die Daten erwarten.
PUT	Aktualisiert eine Ressource. Für APIs mit Update-Endpunkten.
DELETE	Löscht eine Ressource. Für APIs mit Lösch-Endpunkten.
PATCH	Teilweise Aktualisierung. Für APIs mit partiellen Updates.
HEAD	Wie GET, aber ohne Antwort-Inhalt. Spart Bandbreite, wenn du nur den Statuscode brauchst.
OPTIONS	Fragt verfügbare Methoden ab. Nützlich für CORS-Prüfungen.

Standard: GET

Ohne Auswahl wird automatisch GET verwendet – passend für die meisten Fälle.

Eigene Header

Du kannst eigene HTTP-Header als Key-Value-Paare hinzufügen, wenn dein Endpunkt bestimmte Header erwartet.

Header	Wert	Zweck
`Authorization`	`Bearer dein-token`	Authentifizierung bei geschützten APIs
`Accept`	`application/json`	JSON-Antwort anfordern
`Content-Type`	`application/json`	Format des Request Body angeben
`X-API-Key`	`dein-api-key`	API-Schlüssel mitsenden

Lieber die Authentifizierung nutzen

Für Zugangsdaten musst du keinen Header von Hand setzen -- nutze das strukturierte Feld Authentifizierung (siehe unten). Secrets werden dort verschlüsselt gespeichert.

Der Eigene-Header-Editor mit sichtbarem Namen und maskiertem, verschlüsseltem Wert — Eigene Header: Name sichtbar, Wert verschlüsselt (••••••) – leer lassen behält den bestehenden Wert.

Weiterleitungen folgen

Legt fest, ob LIVCK HTTP-Weiterleitungen (Redirects) automatisch folgt.

Ja (Standard): LIVCK folgt Weiterleitungen (z.B. http:// → https://) und prüft das endgültige Ziel.
Nein: LIVCK prüft nur die erste Antwort. Ein Redirect-Statuscode (301, 302) wird als Ergebnis gewertet.

Deaktiviere das Folgen, wenn du explizit prüfen willst, ob ein Redirect korrekt konfiguriert ist.

SSL-Verifizierung

Legt fest, ob das SSL-Zertifikat des Ziels überprüft wird.

Ja (Standard): Ein ungültiges Zertifikat führt zu einem Fehler.
Nein: LIVCK akzeptiert jedes Zertifikat, auch selbstsignierte.

Selbstsignierte Zertifikate

Deaktiviere die SSL-Verifizierung nur bei selbstsignierten Zertifikaten in Test- oder Entwicklungsumgebungen. Für Produktion sollte sie immer aktiv sein.

IP-Version

Auto (Standard): LIVCK versucht beide Versionen, Online wenn eine erreichbar ist.
IPv4: Erzwingt IPv4 (kein Fallback).
IPv6: Erzwingt IPv6 (kein Fallback).

Wann erzwingen?

Wähle IPv4 oder IPv6 nur, wenn du gezielt eine Protokoll-Version testen willst. Diese Option gibt es auch bei TCP-, Ping- und SSL-Checks.

Bietet ein Host sowohl IPv4 als auch IPv6 an, ist aber nur eine der beiden Adressfamilien erreichbar, meldet LIVCK statt Online den Status Beeinträchtigt. So fällt sofort auf, wenn z.B. nur die IPv6-Anbindung klemmt, während IPv4 noch läuft. Die Option greift nur bei IP-Version Auto.

Client-Zertifikat & eigene CA (mTLS)

Für APIs mit gegenseitiger TLS-Authentifizierung (mTLS) kannst du ein Client-Zertifikat referenzieren, das LIVCK beim Verbindungsaufbau vorlegt. Zusätzlich lässt sich ein eigenes CA-Zertifikat hinterlegen -- damit werden auch interne oder selbstsignierte Zertifikate als vertrauenswürdig behandelt, ohne die SSL-Verifizierung ganz abzuschalten.

Beide Optionen stehen bei HTTP- und SSL-Checks zur Verfügung. Die Zertifikate werden zentral in deiner Organisation verwaltet und verschlüsselt gespeichert.

Bedingungen

Mit Bedingungen legst du fest, wann ein Service Online, Offline oder Beeinträchtigt ist. Für HTTP-Checks kannst du prüfen:

Statuscode (z.B. ungleich 200 → Offline)
Antwortzeit in ms (z.B. > 2000 → Beeinträchtigt)
Antwort-Inhalt (Body enthält / enthält nicht einen Text)
JSON-Feld über einen Pfad wie json.data.status -- echter Health-Check
Antwort-Header wie header.content-type

Alle Felder, Operatoren und ausführliche Beispiele findest du unter Bedingungen.

Standard-Verhalten

Ohne eigene Bedingungen gilt:

Statuscode 200--399 = Online
Timeout oder Verbindungsfehler = Offline
Statuscode 400 oder höher = Offline

Für die meisten Websites reicht das aus.

Typische Anwendungsfälle

Website überwachen

Methode: GET
Ziel: https://www.deinefirma.de
Bedingung: Statuscode = 200 (oder Standard)

API-Endpunkt überwachen

Methode: GET
Ziel: https://api.deinefirma.de/health
Header: Accept: application/json
Bedingung: Body enthält "healthy"

Methode: GET
Ziel: https://app.deinefirma.de/login
Bedingung: Statuscode = 200, Body enthält "Anmelden"

Verfügbarkeit

HTTP/HTTPS-Checks sind in allen Plänen verfügbar – auch im Free-Plan.

Weiterführende Themen

Check-Einstellungen -- Intervall, Timeout und Wiederholungen konfigurieren
Bedingungen -- Eigene Regeln für Online/Offline/Beeinträchtigt definieren
Services verwalten -- Services erstellen und verwalten
Service-Detailseite -- Ergebnisse und Statistiken ansehen