Synthetic Monitoring & Uptime für SaaS
Wenn der Login klemmt oder der Checkout still stehen bleibt, verlieren Sie Umsatz und Vertrauen, lange bevor ein Server-Ping etwas meldet. XICTRAQ stellt Ihre kritischen User-Flows mit echten Browsern nach, prüft API-Endpunkte gegen SLO-Schwellen und belegt Verfügbarkeit gegenüber Kunden.
Erreichbar heißt nicht funktionsfähig
Bei einem SaaS-Produkt zahlt nicht die Startseite die Rechnung, sondern der Weg vom Login über das Onboarding bis zur ersten erfolgreichen Aktion. Genau diese Wege sind aber am verletzlichsten: Ein einzelnes fehlerhaftes Frontend-Deployment, ein abgelaufenes Token oder eine langsame Datenbankabfrage kann den Bezahlvorgang lähmen, während der Webserver weiterhin brav mit HTTP 200 antwortet. Ein reiner Erreichbarkeits-Check sieht davon nichts.
Synthetic Monitoring schließt diese Lücke. Statt nur eine Verbindung zu öffnen, fährt ein echter Browser den definierten Ablauf ab — er klickt, tippt, wartet auf Reaktionen und prüft per Assertion, ob das erwartete Element erscheint. Erst wenn der Bezahl-Dialog tatsächlich auftaucht oder das Dashboard nach dem Login lädt, gilt der Schritt als bestanden. Ein einstellbarer Retry fängt kurzlebige Aussetzer ab, damit nicht jeder einzelne Ruckler sofort als Vorfall durchschlägt.
Daneben lebt jede moderne Web-App von ihrer API. Login-Tokens, Webhooks, Suchanfragen und Bezahl-Endpunkte bilden das Rückgrat — und sollten nicht nur antworten, sondern innerhalb klarer Zeit- und Inhaltsgrenzen antworten. XICTRAQ behandelt diese Grenzen als messbare Service-Level-Objectives, nicht als vages Bauchgefühl. Mit 21 Modulen vom Browser- und API-Monitoring über Web Vitals bis zu Statusseite und Reporting deckt die Plattform die Wege ab, an denen Ihr Umsatz wirklich hängt.
Der kritische Flow als Schritt-Timeline
Jeder Schritt trägt eine Assertion. Erst wenn sie greift, gilt der Schritt als bestanden — sonst Screenshot und Alarm.
Login
Checkout
Onboarding
Bricht eine Assertion, wiederholt der eingestellte Retry den Schritt bis zu dreimal, bevor ein Vorfall entsteht — so trennt die Plattform echte Ausfälle von kurzlebiger Flakiness. Eingegebene Zugangsdaten werden verschlüsselt gespeichert, nie im Klartext.
Was Sie konkret absichern
Acht Bausteine, die zusammen den Unterschied zwischen läuft und funktioniert abbilden.
Login-Flow als Skript
Ein echter Browser durchläuft Anmeldung, Eingabe und Weiterleitung — mit Assertion auf das erwartete Dashboard-Element und einstellbarem Retry gegen Flakiness.
Checkout & Onboarding
Mehrstufige Wege wie Bezahlung oder Erst-Setup werden Schritt für Schritt nachgestellt und bei Abbruch gemeldet; ein Screenshot hält den Fehlerschritt fest.
API-Schwellen (SLO)
Status-Code, Antwortzeit, JSON-Felder und Schema-Form lassen sich gegen frei definierte SLO-Grenzen prüfen — pro Endpunkt einzeln.
Multi-Node-Konsens
Drei EU-Messknoten in Nürnberg, Helsinki (Finnland) und Falkenstein prüfen parallel; ein Ausfall zählt erst, wenn mehrere Knoten ihn bestätigen.
Statusseite & SLA-Report
Eine öffentliche Statusseite informiert Kunden in Echtzeit; SLA-Reports belegen Verfügbarkeit und MTTR als exportierbares PDF.
Web Vitals
LCP, CLS und INP werden mitgemessen, damit ein langsameres Release auffällt, bevor Nutzer abspringen oder kündigen.
Eskalierende Alarme
Bleibt ein Alarm unbestätigt, wandert er über Stufen zum nächsten On-Call-Kontakt — per E-Mail, Slack, Teams, Telegram, Discord oder Webhook.
SSL & Domain im Blick
Ablaufende Zertifikate und Domain-Fristen melden sich rechtzeitig, statt einen Ausfall am Wochenende auszulösen.
Kritische Flows als wiederholbares Skript
Ein Browser-Monitor ist im Kern ein kleines Drehbuch: Seite öffnen, Cookie-Hinweis schließen, E-Mail-Feld füllen, Passwort eingeben, absenden, auf das Dashboard-Element warten. Jeder Schritt kann eine Assertion tragen — ein Text, ein sichtbares Element, eine URL nach Weiterleitung. Bricht eine Zusicherung, wird der genaue Schritt protokolliert und ein Screenshot des Fehlerbildes festgehalten. So sehen Sie nicht nur, dass etwas kaputt war, sondern an welcher Stelle und wie es zum Zeitpunkt des Fehlers aussah.
Ein typischer Einwand lautet: Browser-Skripte seien flaky und produzierten ständig Fehlalarme. Genau dafür gibt es den Retry je Schritt (0 bis 3 Wiederholungen, standardmäßig aus). Ist er gesetzt, wird ein Schritt, der einmal an einem langsamen Frame scheitert, wiederholt, bevor ein Vorfall ausgelöst wird; erst wenn der Fehler stabil bleibt, schlägt das System Alarm. Zugangsdaten für Testaccounts werden verschlüsselt gespeichert und im Editor nach dem Speichern nicht wieder angezeigt. Damit lässt sich ein echter Login messen, ohne ein Sicherheitsrisiko zu schaffen.
Wann lohnt sich der Aufwand? Immer dort, wo ein stiller Fehler direkt Geld kostet: Registrierung, Bezahlung, Onboarding, das Anlegen des ersten Projekts. Für unkritische Marketingseiten genügt oft ein leichter Erreichbarkeits- oder Web-Vitals-Check. Eine praktische Reihenfolge ist, zuerst die ein bis drei Flows zu skripten, deren Ausfall Sie am Wochenende aus dem Bett holen würde, und das Netz danach Schritt für Schritt zu erweitern.
Vom SLA-Versprechen zum messbaren SLO
Im Vertrag steht oft eine Verfügbarkeitszusage, doch ohne Messung bleibt sie ein Wort. Ein Service-Level-Objective macht daraus eine prüfbare Grenze. Pro API-Endpunkt legen Sie fest, welcher Status-Code erwartet wird, wie lange die Antwort höchstens dauern darf und welche Felder die Nutzlast enthalten muss. Eine Suche darf zum Beispiel maximal 400 Millisekunden brauchen und muss ein Array mit Treffern liefern; ein Bezahl-Endpunkt muss mit einem definierten JSON-Schema antworten.
Überschreitet eine Antwort die Latenzgrenze oder fehlt ein erwartetes Feld, gilt der Check als verletzt; schlägt auch die nächste Prüfung fehl, läuft der Alarm über Ihre Kanäle. Für authentifizierte Endpunkte hinterlegen Sie Header oder Tokens, sodass auch geschützte Routen geprüft werden. Da die Antwortzeiten je Endpunkt aufgezeichnet werden, erkennen Sie schleichende Verschlechterungen früh — etwa wenn eine Abfrage über Wochen langsamer wird, lange bevor sie die harte Schwelle reißt.
Worauf sollten Sie beim Setzen der Schwellen achten? Eine zu enge Latenzgrenze erzeugt Rauschen, eine zu weite verschluckt echte Probleme. Bewährt hat sich, mit den real gemessenen Perzentilen zu starten und die Schwelle knapp über dem normalen Spitzenwert zu setzen. Web Vitals ergänzen das Bild auf der Frontend-Seite: Ein API-Aufruf kann schnell sein, während ein großes JavaScript-Bundle die wahrgenommene Ladezeit verschlechtert.
Erreichbarkeits-Check gegen echtes Funktionsmonitoring
Wo ein simpler Ping schweigt — und was ein skriptgesteuerter Ansatz zusätzlich sieht.
Einfacher Ping
- Login-Funktion: Nicht abgedeckt — Server antwortet, auch wenn die Anmeldung hängt
- Checkout-Strecke: Unsichtbar — ein blockierter Bezahl-Button ändert den HTTP-Status nicht
- API-Antwortzeit: Nur „erreichbar / nicht erreichbar“
- API-Inhalt: Wird nicht geprüft
- Fehlalarme: Häufig bei kurzer Netzstörung an einem Standort
- Ladegeschwindigkeit: Keine Aussage
- Störungsanalyse: Manuelles Log-Sammeln
- Kundennachweis: Keine belastbaren Zahlen
- Datenstandort: Variiert je Anbieter
XICTRAQ Synthetic & SLO
- Login-Funktion: Echter Browser meldet sich an und prüft per Assertion das Dashboard-Element
- Checkout-Strecke: Mehrschritt-Skript mit Retry, Screenshot des Fehlerschritts und Schrittprotokoll
- API-Antwortzeit: Frei gesetzte SLO-Schwelle pro Endpunkt, Verletzung löst Alarm aus
- API-Inhalt: JSON-Feld-, Wert- und Schema-Assertions auf die Antwort
- Fehlalarme: Multi-Node-Konsens aus drei EU-Knoten dämpft Einzelausreißer
- Ladegeschwindigkeit: Web Vitals (LCP, CLS, INP) laufen mit und zeigen Regressionen
- Störungsanalyse: Auto-Diagnose bündelt HTTP-Antwort, DNS-Auflösung, Traceroute und Screenshot
- Kundennachweis: Statusseite live + SLA-Report mit Verfügbarkeit und MTTR als PDF
- Datenstandort: Plattform in Deutschland gehostet, Messung in der EU, AVV nach Art. 28
| Aspekt | Einfacher Ping | XICTRAQ Synthetic & SLO |
|---|---|---|
| Login-Funktion | Nicht abgedeckt — Server antwortet, auch wenn die Anmeldung hängt | Echter Browser meldet sich an und prüft per Assertion das Dashboard-Element |
| Checkout-Strecke | Unsichtbar — ein blockierter Bezahl-Button ändert den HTTP-Status nicht | Mehrschritt-Skript mit Retry, Screenshot des Fehlerschritts und Schrittprotokoll |
| API-Antwortzeit | Nur „erreichbar / nicht erreichbar“ | Frei gesetzte SLO-Schwelle pro Endpunkt, Verletzung löst Alarm aus |
| API-Inhalt | Wird nicht geprüft | JSON-Feld-, Wert- und Schema-Assertions auf die Antwort |
| Fehlalarme | Häufig bei kurzer Netzstörung an einem Standort | Multi-Node-Konsens aus drei EU-Knoten dämpft Einzelausreißer |
| Ladegeschwindigkeit | Keine Aussage | Web Vitals (LCP, CLS, INP) laufen mit und zeigen Regressionen |
| Störungsanalyse | Manuelles Log-Sammeln | Auto-Diagnose bündelt HTTP-Antwort, DNS-Auflösung, Traceroute und Screenshot |
| Kundennachweis | Keine belastbaren Zahlen | Statusseite live + SLA-Report mit Verfügbarkeit und MTTR als PDF |
| Datenstandort | Variiert je Anbieter | Plattform in Deutschland gehostet, Messung in der EU, AVV nach Art. 28 |
Verfügbarkeit, die Sie belegen können
B2B-Kunden fragen früher oder später nach Zahlen: Wie hoch war die Verfügbarkeit im letzten Quartal, wie schnell wurde ein Ausfall behoben, gibt es eine Statusseite? XICTRAQ misst über drei verteilte EU-Knoten in Nürnberg, Helsinki (Finnland) und Falkenstein mit Konsens-Logik — ein Vorfall wird erst dann als Ausfall gewertet, wenn ihn mehrere Knoten unabhängig bestätigen. Damit sinkt das Risiko, dass eine kurzzeitige Netzstörung an einem einzelnen Standort als echter Ausfall in Ihre Statistik wandert.
Aus diesen Messungen entsteht eine öffentliche Statusseite, die Sie unter eigener Domain betreiben können. Sie zeigt den Live-Zustand Ihrer Komponenten, historische Verfügbarkeit und geplante Wartungsfenster — proaktiv kommuniziert, statt dass der Support eine Welle gleichlautender Tickets abarbeitet. Im Agency-Plan lässt sich die Seite mit eigenem Logo und eigenen Farben versehen, und Kunden können sich per Double-Opt-in für Störungsmeldungen anmelden. Ein einbettbares Widget bringt den Status direkt in Ihre App oder Ihr Hilfecenter.
Für Verträge und Reviews erzeugt die Plattform SLA-Reports mit Verfügbarkeit in Prozent, Ausfallzeiten und mittlerer Wiederherstellungszeit (MTTR) als exportierbares PDF. Tritt ein Vorfall ein, sammelt die Auto-Diagnose den Kontext — HTTP-Antwort, DNS-Auflösung, Traceroute und ein Screenshot des Fehlerbildes — damit Ihr Team nicht erst Logs zusammensuchen muss. Diese Verkürzung der Analysephase wirkt direkt auf die MTTR, weil die Zeit bis zur ersten belastbaren Hypothese sinkt.
Ein Vorfall, Schritt für Schritt
- 1
Stellen Sie sich vor, ein Deployment bricht den Bezahl-Endpunkt. Der erste Messknoten meldet eine verletzte SLO-Schwelle, ein zweiter bestätigt sie kurz darauf — der Konsens greift, und der Vorfall wird eröffnet. Parallel fängt der Browser-Monitor den Checkout im Fehlerzustand ein und legt einen Screenshot bei. Die Auto-Diagnose hängt HTTP-Antwort, DNS-Auflösung und Traceroute an, sodass im Incident bereits steht, dass Namensauflösung und Netzpfad in Ordnung sind und das Problem auf Anwendungsebene liegt.
- 2
Der Alarm geht über den ersten Kanal raus, zum Beispiel Slack und E-Mail. Reagiert niemand innerhalb der gesetzten Frist, eskaliert er an den nächsten On-Call-Kontakt — so bleibt ein Nachtausfall nicht liegen, nur weil eine Person das Telefon stummgeschaltet hat. Auf der öffentlichen Statusseite erscheint die betroffene Komponente automatisch als gestört, und angemeldete Kunden erhalten eine Benachrichtigung, ohne dass jemand manuell ein Update tippen muss.
- 3
Ist die Ursache behoben, schließt sich der Vorfall, sobald die Knoten wieder grün melden. Im nächsten SLA-Report taucht das Ereignis mit Dauer und Wiederherstellungszeit auf, ohne dass jemand eine Tabelle pflegen muss. Genau dieser durchgängige Pfad — Erkennung, Diagnose, Eskalation, Kommunikation, Nachweis — ist der Unterschied zwischen hektischem Reagieren und einem nachvollziehbaren Prozess.
Die passenden Module im Detail
Häufige Fragen
Wie überwache ich einen Login-Flow Schritt für Schritt?
Sie hinterlegen die Schritte als Browser-Monitor: Seite öffnen, Zugangsdaten eintragen, absenden, auf das erwartete Element nach der Anmeldung warten. Ein echter Browser führt diese Schritte in festen Intervallen aus. Schlägt eine Assertion fehl — etwa weil das Dashboard nicht lädt — wird ein Alarm ausgelöst und ein Screenshot des Fehlerzustands gespeichert. Eingegebene Zugangsdaten werden verschlüsselt gespeichert, nicht im Klartext, und ein einstellbarer Retry (bis zu drei Wiederholungen je Schritt) trennt echte Ausfälle von kurzlebiger Flakiness.
Wodurch unterscheidet sich Synthetic Monitoring von einem reinen Ping?
Ein einfacher Ping prüft nur, ob der Server antwortet. Synthetic Monitoring stellt dagegen eine echte Nutzerinteraktion nach und prüft per Assertion, ob das Ergebnis stimmt. Ein Checkout kann auf Server-Ebene erreichbar sein, während der Bezahl-Button durch einen JavaScript-Fehler nicht reagiert. Genau solche Fälle erkennt ein skriptgesteuerter Browser-Monitor, ein Ping nicht.
Kann ich API-Endpunkte mit SLO-Schwellen prüfen?
Ja. Pro Endpunkt definieren Sie erwarteten Status-Code, eine maximale Antwortzeit und optional Prüfungen auf einzelne JSON-Felder, deren Werte oder die Schema-Form. Wird eine dieser Schwellen überschritten, gilt der Check als verletzt; schlägt auch die nächste Prüfung fehl, geht ein Alarm raus. So machen Sie ein Service-Level-Objective messbar, statt es nur als Versprechen im Vertrag stehen zu haben. Authentifizierte Endpunkte lassen sich über hinterlegte Header oder Tokens prüfen.
Wie verhindert XICTRAQ Fehlalarme bei kurzen Netzstörungen?
Die Messung läuft über drei verteilte EU-Knoten in Nürnberg, Helsinki und Falkenstein. Meldet nur ein Knoten ein Problem, behandelt die Konsens-Logik das zunächst als Einzelausreißer; erst wenn mehrere Knoten den Fehler unabhängig bestätigen, wird er als Ausfall gewertet. Dadurch wandert eine kurzzeitige Routingstörung an einem einzelnen Standort seltener als echter Ausfall in Ihre Statistik.
Gibt es SLA-Reports mit MTTR für meine Kunden?
XICTRAQ erzeugt automatische Berichte mit Verfügbarkeit in Prozent, Ausfallzeiten und mittlerer Wiederherstellungszeit (MTTR) über den gewählten Zeitraum. Diese Reports lassen sich als PDF exportieren und im Agency-Plan mit eigenem Logo und eigenen Farben versehen — passend, wenn Sie Verfügbarkeit gegenüber eigenen Kunden nachweisen.
Hilft mir die Plattform bei der Störungsanalyse?
Bei einem Vorfall sammelt die Auto-Diagnose den Kontext automatisch: HTTP-Antwort mit Zeiten und Server-IP, DNS-Auflösung, ein Traceroute und ein Screenshot des Fehlerbilds. Statt erst Logs zusammenzusuchen, sehen Sie den wahrscheinlichen Ausgangspunkt direkt im Incident — das verkürzt die Zeit bis zur ersten Hypothese und damit tendenziell die MTTR.
Was kostet die Überwachung und gibt es einen kostenlosen Einstieg?
Es gibt einen dauerhaft kostenlosen Plan, mit dem Sie erste Monitore anlegen und die Oberfläche kennenlernen. Bezahlte Pläne beginnen bei 12 Euro pro Monat, monatlich kündbar, und schalten mehr Monitore, kürzere Intervalle und erweiterte Funktionen frei. Browser-Monitore mit komplexen Flows und White-Label-Statusseiten liegen in den höheren Plänen.
In welchen Abständen wird gemessen und wie schnell kommt ein Alarm?
Das Prüfintervall hängt vom Plan und vom Monitortyp ab und reicht von kurzen Takten für kritische Endpunkte bis zu entspannteren Intervallen für unkritische Seiten. Wird eine Schwelle verletzt oder eine Assertion bricht, läuft der Alarm über Ihre konfigurierten Kanäle, bei API-Checks nach zwei fehlgeschlagenen Prüfungen in Folge. Bleibt er unbestätigt, eskaliert er stufenweise an den nächsten On-Call-Kontakt, damit ein Nachtausfall nicht unbemerkt liegen bleibt.
Kann ich eine eigene Statusseite unter meiner Domain betreiben?
Ja. Die öffentliche Statusseite zeigt den Live-Zustand Ihrer Komponenten, historische Verfügbarkeit und geplante Wartungsfenster. Sie lässt sich über einen CNAME unter eigener Domain ausliefern; im Agency-Plan kommen Logo, Farben und Firmenname dazu. Kunden können sich per Double-Opt-in für Störungsmeldungen anmelden, und ein einbettbares Widget bringt den Status direkt in Ihre App.
Wo laufen die Messknoten und wo liegen meine Daten?
Die Messung erfolgt über drei verteilte EU-Knoten in Nürnberg, Helsinki und Falkenstein; Helsinki liegt in Finnland, nicht in Deutschland. Die Plattform selbst wird in Deutschland gehostet, Ihre Daten verbleiben in der EU, und einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO stellen wir bereit. Die rechtliche Bewertung im Einzelfall liegt bei Ihnen.
Sichern Sie die Wege ab, die Umsatz tragen
Starten Sie mit dem dauerhaft kostenlosen Plan und legen Sie Ihren ersten Login- oder Checkout-Monitor an. Bezahlte Pläne beginnen bei 12 € pro Monat, monatlich kündbar, ein AVV nach Art. 28 DSGVO ist verfügbar, gehostet in Deutschland.