Browser-Monitoring (Synthetics)
Mehrstufige Flows (Login, Checkout, Formular) laufen in einem echten Chromium-Browser. Schlägt ein Schritt fehl, bekommen Sie einen Alert mit der genauen Step-Nummer und Fehlermeldung; der Failure-Screenshot liegt im Run-Detail.
# Monitor + Run-Historie
# Step-Typen im Builder
Ein Szenario ist eine Liste von bis zu 40 Schritten. Jeder Schritt hat einen Typ und dazu passende Felder. Optional lässt sich pro Schritt ein Wiederholungszähler (retry, 0–3) für instabile Selektoren setzen.
URL aufrufen, wartet auf networkidle. Liefert die Antwort einen Fehlerstatus (kein 2xx/3xx), gilt der Schritt als fehlgeschlagen. Der HTTP-Status wird für ein späteres assert_status gemerkt.
Felder: url
CSS-Selector klicken. Wartet auf sichtbares Element.
Felder: selector
Feldwert setzen (Text, E-Mail, Passwort). Bestehende Inhalte werden überschrieben.
Felder: selector + value
Wie fill, aber zeichenweise getippt — für Komponenten die auf input-Events Zeichen-für-Zeichen reagieren (Autocomplete, Masked-Inputs).
Felder: selector + value
Bis Selector im DOM sichtbar ist (konfigurierbares Timeout).
Felder: selector
Statische Pause, 100–30 000 ms. Vorsichtig einsetzen — meistens besser wait_for.
Felder: ms
Text des Selectors muss einen Substring enthalten (contains, case-sensitive) oder exakt gleich sein (equals).
Felder: selector + contains | equals
Aktuelle URL muss Substring enthalten (z. B. "/dashboard").
Felder: contains
Letzte Navigation muss einen erwarteten Status zurückgeliefert haben (z. B. 200).
Felder: status
Selector muss im DOM vorhanden und sichtbar sein.
Felder: selector
Nimmt ein Bildschirmfoto auf (PNG), wird im Run-Detail angezeigt. Mit full_page=true die ganze Seite statt nur des Viewports.
Felder: full_page?
# Szenario-JSON & Optionen
Jedes Szenario ist ein JSON-Objekt mit einer steps-Liste. Zusätzlich zu den Schritten lassen sich Viewport, ein globales Schritt-Timeout und ein Standard-Retry für die gesamte Liste setzen. Der Builder im Dashboard erzeugt genau diese Struktur — fortgeschrittene Anwender bearbeiten sie direkt.
Aufbau eines Szenarios
Ein typischer Login-Flow: Seite öffnen, Felder füllen, Submit klicken, auf das Dashboard warten und Text plus URL prüfen. viewport (Standard 1280×800) und timeout_ms (globales Schritt-Timeout, 5 000–60 000 ms, Standard 30 000) sind optional. Pro Schritt überschreibt timeout_ms (1 000–60 000 ms) das globale Timeout.
{
"name": "Login-Flow",
"viewport": { "width": 1280, "height": 800 },
"timeout_ms": 30000,
"step_retry": 1,
"steps": [
{ "type": "goto", "url": "https://example.com/login" },
{ "type": "fill", "selector": "#email", "value": "monitor@example.com" },
{ "type": "fill", "selector": "#password", "value": "***" },
{ "type": "click", "selector": "button[type=submit]" },
{ "type": "wait_for", "selector": ".dashboard", "timeout_ms": 10000 },
{ "type": "assert_text", "selector": "h1", "contains": "Willkommen" },
{ "type": "assert_url", "contains": "/dashboard" }
]
}Retry gegen Flakiness (linearer Backoff)
Schlägt ein Schritt fehl, wird er bis zu retry-mal (0–3) wiederholt, bevor der Lauf als fehlgeschlagen gilt. Der Wert kommt vom einzelnen Schritt (retry) oder als step_retry vom ganzen Szenario (Standard 0). Zwischen den Versuchen wartet der Runner linear länger (500 ms × Versuch). Nutzen Sie das sparsam — ein gezieltes wait_for vor dem nächsten Schritt ist bei SPA-Races meist die sauberere Lösung.
Eigener User-Agent & Tracker-Block
Jeder Lauf sendet den User-Agent XICTRAQ-BrowserMonitor/1.0 (per Szenario via user_agent überschreibbar). Der Runner blockt zusätzlich den XICTRAQ-Tracker (t.js sowie die /api/p- und /api/e-Endpunkte), damit synthetische Läufe Ihre eigene Analytics nicht mit Test-Pageviews verschmutzen.
SSRF-Schutz für jede URL
Jede goto-URL muss eine öffentlich erreichbare http/https-Adresse sein. Interne oder private Ziele (localhost, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, Link-local, IPv6-ULA u. a.) werden abgelehnt — sowohl beim Speichern als auch erneut unmittelbar vor jedem Lauf (mit DNS-Auflösung, fängt also auch DNS-Rebinding ab). Eine blockierte URL beendet den Lauf mit einer klaren Fehlermeldung, statt interne Inhalte abzurufen.
# Run-Historie & Screenshots
Jeder Lauf wird mit Gesamtdauer, Ergebnis und Pro-Schritt-Resultaten gespeichert. Die Übersicht zeigt die letzten 50 Läufe je Monitor.
Pro-Schritt-Resultate
Pro Lauf werden Start- und Endzeit, duration_ms, ok, der Index des fehlgeschlagenen Schritts (failed_step) und eine Fehlermeldung festgehalten. Für jeden Schritt sind Typ, Dauer, Erfolg/Fehler und — je nach Typ — der tatsächlich gefundene Text, die aktuelle URL oder der HTTP-Status protokolliert. So sehen Sie genau, welcher Schritt wie oft und mit welcher Meldung bricht.
Jetzt ausführen (Run now)
Mit „Jetzt ausführen“ stellen Sie einen Monitor fällig — der nächste Cron-Tick (jede Minute) greift ihn auf und führt den Flow aus, ohne das nächste Intervall abzuwarten. Praktisch, um nach einem Deploy oder während eines offenen Alerts zu prüfen, ob der Flow wieder grün ist.
Screenshots privat gespeichert
Failure-Screenshots (bei Fehler) und bewusste screenshot-Schritte werden in einem privaten Verzeichnis abgelegt — nicht öffentlich, sondern nur über den authentifizierten, mandantengebundenen Endpoint Ihres Kontos abrufbar. Beim Löschen eines Monitors werden die zugehörigen Bilddateien mit aufgeräumt.
# Alerting & Failure-Screenshot
Gleiche Alert-Engine wie Uptime
Fehlschlag erzeugt einen Alert vom Typ browser_monitor_failed mit Severity critical. Dedupe (10 Min), ACK-Link, Eskalation über Default-Policy und Postmortem-Export funktionieren identisch zum normalen Uptime-Alert. Die 10 Minuten sind die Vorgabe; das Fenster lässt sich in den Benachrichtigungs-Einstellungen ändern. Wird der Flow wieder grün, schließt XICTRAQ den Alert automatisch.
Failure-Screenshot automatisch
Bei jedem fehlgeschlagenen Step wird ein Screenshot im Moment des Fehlers aufgenommen (ohne expliziten screenshot-Step) und in der Run-Historie gespeichert. Die Alert-E-Mail verlinkt aufs Dashboard, wo der Screenshot zugriffsgeschützt abrufbar ist — Sie sehen exakt, was der Browser sah, als es brach.
Auto-Resolve bei wieder-OK
Sobald ein Run wieder vollständig grün ist, wird der offene Alert aufgelöst. Keine Alarm-Flut wenn ein Flaky-Selector zwischendurch wieder greift — Dedupe hält standardmäßig 10 Minuten, einstellbar.