Multi-step / API monitoring

Das mehrstufige Monitoring führt als ein einziger Monitor eine Folge von HTTP-Anfragen aus: Es meldet sich an, speichert einen Token, verwendet ihn im nächsten Schritt und prüft die Antwort per JSONPath. Es ist ideal für die Überwachung von APIs und Anmeldeabläufen, bei denen eine einzelne Anfrage nicht ausreicht. Verfügbar in den Tarifen Pro und Business für HTTP-Monitore.

Wo richte ich es ein?

1. Öffnen Sie die Detailseite eines HTTP-Monitors.
2. Fügen Sie im Abschnitt Multi-step / API monitoring die JSON-Liste der Schritte ein und klicken Sie auf Speichern.
3. Ein leeres Feld setzt den Monitor auf eine klassische einzelne Prüfung zurück.

Schrittformat

Schritte sind eine JSON-Liste (max. 10). Jeder Schritt ist ein Objekt mit diesen Feldern:

• url - die Adresse des Schritts (erforderlich). Kann eine Variable enthalten, z. B. .
• method - GET, POST, PUT, PATCH, DELETE, HEAD (Standard GET).
• headers - ein Header-Objekt (optional).
• body - der Anfragetext als Text (optional).
• expect_status - erwarteter HTTP-Status (Standard 200).
• expect_contains - Text, der in der Antwort enthalten sein muss.
• expect_jsonpath + expect_value - ein Pfad in der JSON-Antwort und der erwartete Wert.
• save - ein Objekt Variable → JSONPath; der Wert wird für spätere Schritte gespeichert.
• name - eine in der Fehlermeldung angezeigte Schrittbezeichnung (optional).

Beispiel: Anmeldung + Prüfung

[
  {
    "name": "login",
    "method": "POST",
    "url": "https://api.example.com/auth/login",
    "headers": { "Content-Type": "application/json" },
    "body": "{\"user\": \"demo\", \"pass\": \"...\"}",
    "expect_status": 200,
    "save": { "token": "data.access_token" }
  },
  {
    "name": "profile",
    "url": "https://api.example.com/me",
    "headers": { "Authorization": "Bearer " },
    "expect_jsonpath": "user.active",
    "expect_value": "True"
  }
]

JSONPath

Unterstützt Punktnotation und Array-Indizes: data.items[0].id, user.name, optionales Präfix $..

Gut zu wissen

• Ein mehrstufiger Monitor läuft nur aus der primären Region (der Multiregionen-Konsens wird übersprungen).
• Zieladressen dürfen nicht auf das interne Netzwerk verweisen (gleicher Schutz wie bei normalen Monitoren).
• Variablen aus save gelten nur innerhalb einer einzelnen Prüfung.