Modul · XICTRAQ

API- & Endpoint-Monitoring

Scheduled Checks für REST-APIs mit JSON-Path-Assertions, Header-Auth, Response-Zeiten und Alert-Eskalation. Für SaaS, Integrationen, interne Dienste.

ab Starter-Plan

14 Tage kostenlos testen Live-Demo

Keine Kreditkarte Server in Deutschland 3 EU-Messknoten 14 Tage Pro-Test DSGVO-konform

Live-Status

API- & Endpoint-Monitoring

AKTIV

REST-Endpoints pro Intervall

GET/POST/PUT/PATCH/DELETE/HEAD. Intervall ab 30 Sek (Agency) bis 5 Min (Starter). Timeout 1-30 Sek konfigurierbar.

Custom Headers & Auth

Bearer-Tokens, API-Keys, X-Request-ID — beliebige Header senden. Body-Payloads für POST/PUT mit JSON oder Form-Data.

Status-Code-Assertions

Exakt (== 200), Bereich (200-299), ungleich (!= 500). Granulare Kontrolle statt “einfach nicht 5xx”.

Response-Time-SLOs

Response-Zeit-Assertion pro Check: der Check schlägt fehl, wenn die Antwortzeit über Schwelle X ms liegt. Verlauf pro Endpoint mit Response-Zeit-Graph der letzten 100 Läufe.

Letzter Check just now

Was es leistet

Uptime zu prüfen ist die halbe Miete — die andere ist: antwortet die API auch korrekt? Ein 200-OK reicht nicht, wenn der JSON-Body sagt „error: true“. XICTRAQ ruft Ihre Endpoints im eingestellten Intervall auf, schickt Custom-Headers (Bearer-Tokens, API-Keys), optional Request-Bodies und prüft die Antwort gegen konkrete Erwartungen: HTTP-Status, Response-Zeit, JSON-Path-Werte, Text-Enthält-Checks. Schlagen zwei Prüfungen in Folge fehl, geht der Alarm auf denselben Kanälen hinaus wie bei Ihren Uptime-Checks — E-Mail, Slack, Teams, Discord, Telegram, Webhook.

REST-Endpoints pro Intervall

GET/POST/PUT/PATCH/DELETE/HEAD. Intervall ab 30 Sek (Agency) bis 5 Min (Starter). Timeout 1-30 Sek konfigurierbar.

01 / 06

Custom Headers & Auth

Bearer-Tokens, API-Keys, X-Request-ID — beliebige Header senden. Body-Payloads für POST/PUT mit JSON oder Form-Data.

02 / 06

Status-Code-Assertions

Exakt (== 200), Bereich (200-299), ungleich (!= 500). Granulare Kontrolle statt “einfach nicht 5xx”.

03 / 06

Response-Time-SLOs

Response-Zeit-Assertion pro Check: der Check schlägt fehl, wenn die Antwortzeit über Schwelle X ms liegt. Verlauf pro Endpoint mit Response-Zeit-Graph der letzten 100 Läufe.

04 / 06

JSON-Path-Assertions

Prüfen Sie konkrete Werte im Response-Body: `$.status == "ok"`, `$.data.users[0].email regex "@company.invalid$"`. Volle Operatoren: eq, neq, gt, lt, contains, regex, exists.

05 / 06

Alert auf allen Kanälen

Schlagen zwei Checks in Folge fehl, geht der Alarm über denselben Weg wie beim Uptime-Monitoring hinaus: E-Mail, Slack, Teams, Discord, Telegram, Webhook, samt Eskalation. Ein einzelner Ausreißer steht im Verlauf, löst aber keinen Alarm aus. Der Verlauf markiert fehlgeschlagene Checks farbig, der “Jetzt prüfen”-Debug-Output wertet jede Assertion einzeln aus.

06 / 06

Ablauf

So funktioniert es

Endpoint anlegen

URL, Methode, Intervall. Optional Headers und Body hinzufügen. Assertions bestehen per Default aus HTTP 200-299 — individualisierbar per JSON-Editor.

Jetzt-prüfen-Button

Einen Klick, sofortiger Lauf mit vollem Debug-Output: HTTP-Code, Response-Zeit, Assertion-Auswertung pro Zeile. Testen vor Go-Live.

Verlauf und Alerts

Historie als visueller Zeitstrahl direkt im Dashboard. Bei fehlgeschlagener Assertion wird der Lauf im Verlauf als „Fail“ markiert und der Grund (failure_reason) gespeichert. Schlägt auch die nächste Prüfung fehl, geht der Alarm über Ihre Kanäle hinaus.

FAQ

Häufige Fragen

Wie viele Endpoints sind inklusive?

Free: 0 (nicht enthalten). Starter: 10 Endpoints, 5-Min-Intervall. Business: 25 Endpoints, 1-Min-Intervall. Agency: 100 Endpoints, 30-Sek-Intervall. Jeder Endpoint zählt unabhängig von Aufruf-Volumen.

Welche Assertion-Typen gibt es?

Vier Kerntypen: status_code (HTTP-Status prüfen), response_time_ms (Dauer prüfen), json_path (Wert im JSON-Body extrahieren und prüfen), text_contains (Substring im Body). Operatoren: eq, neq, gt, gte, lt, lte, contains, regex, in_range (z.B. „200-299“), exists. Mehrere Assertions werden UND-verknüpft — alle müssen passen.

Werden API-Endpoints aus mehreren Regionen geprüft?

Aktuell laufen API-Endpoint-Checks zentral aus dem Monitoring-Knoten n0. Multi-Region (alle drei Knoten n0, n1, n2 mit 2-of-3-Konsens) ist heute für Uptime-Monitoring aktiv und für API-Endpoint-Checks auf der Roadmap.

Wie stoppe ich Alert-Fluten bei bekanntem Ausfall?

Jeder Endpoint kann einzeln pausiert werden (Schaltfläche „Pausieren“). Für geplante Wartungen greifen die globalen Wartungsfenster Ihrer Website-Einstellungen.

Kann ich Endpoints hinter Authentifizierung prüfen?

Ja. Im Headers-Feld einfach `Authorization: Bearer TOKEN` eintragen. XICTRAQ speichert den Header-Wert verschlüsselt (AES, App-Key). Für rotierende Tokens empfehlen wir einen long-lived Service-Account-Token mit Read-only-Rechten und enger Scope-Begrenzung. Status-Codes (401, 403) werden dann sauber als Fehlschlag im Verlauf erfasst.

Was unterscheidet das vom normalen Uptime-Monitoring?

Uptime prüft: „Ist die Website grundsätzlich erreichbar?“ API-Monitoring prüft: „Antwortet dieser spezifische Endpoint auch semantisch korrekt?“ Beispiel: Ihr Checkout könnte 200 zurückgeben, aber im JSON `payment_status: "failed"`. Uptime sieht grün, API-Monitoring rot. Beide zusammen decken den gesamten Request-Lifecycle ab.