PathAugust 2026
10.000 Prüfungen pro Tag
Pathly führt inzwischen 10.000 Prüfungen pro Tag aus. Die Zahl selbst sagt nichts; was dafür zu reparieren war, schon.
Was diese Zahl zählt
Diese 10.000 täglichen Prüfungen mischen zwei sehr ungleiche Dinge. Der Großteil sind HTTP-Aufrufe: sie kosten einige Dutzend Millisekunden und kommen jede Minute wieder. Der Rest sind Browser-Abläufe: ein echtes Chromium, das eine Seite öffnet, klickt, ein Formular füllt und prüft, ob ein erwarteter Text erscheint. Sie kosten tausendfach mehr und laufen daher viel seltener.
Der Zähler enthält unsere eigenen Demo-Abläufe und Testkonten. Wir verkaufen ihn nicht als Traktion: er misst Last, nicht Umsatz.
Was dieses Volumen lehrt
Die erste Lektion ist unangenehm: die meisten Fehler, die wir sahen, kamen nicht von den überwachten Seiten, sondern von unseren eigenen Szenarien. Ein zu präziser Selektor, ein Consent-Banner, das an jedem dritten Tag erscheint, ein Timeout, das auf ein schnelles Netz eingestellt war. Ein Monitoring-Werkzeug, das falschen Alarm schlägt, verliert binnen zwei Wochen seinen Zweck: dort steckt der Großteil der Arbeit.
Die zweite ist nützlicher: wenn ein Ablauf wirklich bricht, dann fast immer wegen etwas, das nicht zur Seite gehört. Ein Zahlungsskript, eine Bibliothek von einer Fremddomain, ein Consent-Dienst, eine entfernte Schriftart. Die Seite hat sich nicht geändert — ihr Umfeld schon.
Eine Teststadt, und wir sagen das
Alle unsere Abläufe starten in Europa. Lange haben wir eine Auswahl von sieben Städten angezeigt, während tatsächlich nur eine Sonde lief: eine Messung konnte im Bericht als „Madrid“ erscheinen. Das war falsch, und wer pro Stadt eine Ausführung bezahlte, zahlte zweimal für dieselbe Messung. Wir haben die Scheinauswahl entfernt, statt sie weiterleben zu lassen. Die anderen Städte kommen zurück, wenn die zugehörige Sonde existiert.
Wie es weitergeht
Drei Baustellen, in dieser Reihenfolge: Szenarien toleranter gegenüber kleinen Oberflächenänderungen machen, ohne sie für echte Ausfälle blind zu machen; eine zweite Teststadt eröffnen, wenn das Volumen es rechtfertigt; und die Zeit zwischen Fehler und Alarm verkürzen — die einzige Kennzahl, die ein Kunde behält.