Ein Spediteur, mit dem wir arbeiten, nutzt einen Browser-Agenten. Er meldet sich alle zehn Minuten an. In einem Kundenportal. Seit Ende Juli über 6.500 Mal. 6.498 davon erfolgreich. 22 Fehler. 18 Warnungen. Das ist eine Quote von 99,4 Prozent.
Die Zahl ist nicht die Geschichte. Wer nur auf die Quote schaut, hat noch nichts gesehen. Die Geschichte steht in einem Lauf. In den Zeilen, die er ins Protokoll schreibt. Genau die Zeilen zeigen, ob ein Prozess ohne Aufsicht vertrauenswürdig ist. Oder nur zufällig grün.
Ein Lauf am Nachmittag, 14:05 Uhr, dauert 30 Sekunden. Jede Sekunde davon ist eine Zeile im Protokoll.
Modul Login, rund eine Sekunde. Drei Schritte: Zugangsdaten aus dem Vault holen. Formular abschicken. Ergebnis prüfen. Kein Passwort im Code. Kein Passwort in einer Liste. Der Agent liest das Secret erst im Moment des Logins.
Modul Export, rund 22 Sekunden. Drei Schritte: Zeitfenster berechnen. Export anfordern. Export prüfen. Das Portal liefert eine XML-Datei. Mit dem Stand aller offenen Teilstrecken. Diese 22 Sekunden sind der teuerste Teil des Laufs. Das Portal selbst braucht so lange.
Modul Transform, rund 50 Millisekunden. Drei Schritte: XML parsen. Offene Ist-Zeiten filtern. Nach Priorität sortieren. Hier trifft die Portal-Sicht auf den eigenen Stand. Was im Portal offen ist, aber im TMS erledigt, fällt heraus.
Modul Publish, rund fünf Sekunden. Zwei Schritte: Liste aufbauen. An den Planer übergeben. Das Ergebnis liegt jetzt dort, wo die Disposition ohnehin hinschaut. Kein zusätzliches Fenster. Kein zusätzliches Portal.
Vier Module. Elf Schritte, jeder mit Namen. Ein Eintrag je Schritt. Nicht "Lauf erfolgreich". Sondern: welcher Schritt. Wie lange. Mit welchem Ergebnis.
Ein Portal ohne API hat trotzdem eine Oberfläche. Für Menschen gebaut. Ein Agent muss darin Elemente finden. Das Login-Feld. Den Export-Knopf. Die Tabelle mit den Teilstrecken.
Der einfache Weg ist Position. Das dritte Feld. Die zweite Spalte. Der vierte Knopf von links. Dieser Weg bricht beim nächsten Update. Eine neue Spalte, ein Feld verschiebt sich, und der Agent klickt daneben. Ohne es zu merken.
Der bessere Weg ist Bedeutung. Das Feld mit dem Label "Name". Der Knopf mit dem Text "Export anfordern". Die Zeile mit einer Auftragsnummer. Ein Update ändert oft das Layout. Es ändert seltener den Text. Den muss ja auch der Mensch beim Kunden noch lesen können. Genau diese Änderungen zerstören einen Selektor nach Position sofort. Ein Selektor nach Bedeutung überlebt sie.
Beide Wege können trotzdem scheitern. Der Unterschied liegt in dem, was danach passiert.
Am 24. August, zwischen 20:26 und 21:26 Uhr, scheitert der Login viermal in Folge. Immer der gleiche Fehler. HTTP 500. Das Portal selbst antwortet nicht. Jeder Absturz landet erst bei einem Mail-Fallback. Still. Ohne Alarm für einen Menschen. Nach dem vierten Fehllauf pausiert die Pipeline sich selbst. Für 120 Minuten. Die Meldung im Protokoll sagt nicht nur "Login fehlgeschlagen". Sie sagt genauer: Portal-Störung, kein Problem mit dem Passwort. Der Agent unterscheidet selbst. Falsches Passwort oder Störung beim Anbieter.
Am 10. September wiederholt sich das Muster. Kleiner. Zwei Abstürze im Zehn-Minuten-Takt. Die Verbindung bricht einfach ab. Dann eine Pause von 30 Minuten. Nach drei Fehlläufen statt vier. Kürzere Pause, weniger Fehlläufe. Die Regel ist gestuft, nach Schweregrad.
Ein dritter Auslöser hat mit einem Absturz nichts zu tun. Die Laufzeit selbst. Der Median liegt bei 28 Sekunden. Braucht ein Lauf 162 Sekunden, das 5,8-Fache, pausiert die Pipeline vorsorglich. Das Portal antwortet noch. Nur spürbar langsamer als sonst. Genau da würde ein Mensch am Bildschirm ungeduldig. Der Agent wird vorsichtig. Bevor er scheitert.
Alle drei Regeln teilen eines. Die Pause endet nicht am nächsten Termin. Sie endet erst, wenn ein Lauf wieder normal verläuft. Ohne diese Regel würde die Pipeline sofort neu starten. Nach jeder Störung. Und sofort wieder scheitern. Alle zehn Minuten. Den ganzen Tag.
Der Monitor zeigt nicht "Lauf 08:15 Uhr: Fehler". Er zeigt die Sektion, in der es klemmte. Den genauen Fehlertext. Und, wenn einer griff, ob ein Fallback schon half. Ein Fehler mit Fallback und erfolgreicher Mail braucht am Morgen keinen Blick. Ein Fehler ohne Fallback braucht ihn direkt.
Genau darum ist eine Alarm-Mail bei jedem Fehler der falsche Reflex. 22 Fehler in sieben Wochen wären 22 Mails. Die meisten ohne offenen Punkt. Der Fallback hat schon gegriffen. Der Monitor sammelt stattdessen einen Status. Offen. Automatisch behoben. Wartet auf das Portal. Der Disponent liest morgens eine Zeile. Nicht 22.
Ein Bild ergänzt das nur bei echter Abweichung. Nicht bei jedem Lauf. Sonst ertrinkt der Monitor in Bildern von Anmeldeseiten, die aussehen wie immer.
Ein Selektor nach Bedeutung hält länger. Nicht ewig. Ändert das Portal den Text eines Knopfes, bricht auch dieser Weg. Etwa von "Export anfordern" zu "Daten exportieren". Der Unterschied ist nur, wie oft das passiert.
Die Regel mit der Hysterese schützt vor Flattern. Sie verzögert aber auch die Sicht auf einen echten, langen Ausfall. Um bis zu zwei Stunden. Für einen Zehn-Minuten-Takt ist das vertretbar. Für einen Lauf pro Stunde, mit wenigen Terminen am Tag, wäre die gleiche Regel zu träge.
Die Unterscheidung Portal-Störung gegen Passwort-Problem kennt der Agent nur aus einem Grund. Jemand hat beide Fälle vorher benannt. Ein neuer Fehler, den niemand vorgesehen hat, landet erst unspezifisch im Protokoll. Das Protokoll ist ehrlicher als eine Meldung "erfolgreich". Einen Menschen, der es liest, ersetzt es nicht.
Zwei andere Beiträge gehen tiefer. Der erste: Ein Kundenportal ohne Schnittstelle ist kein Blocker. Der zweite: "Job lief" ist kein Gesundheitsbeweis. Dieser Beitrag zeigt nur die Innenansicht eines Laufs. Nicht die Grundsatzfrage.
Wie oft pausiert Ihr Portal-Prozess sich selbst, ohne dass es jemand merkt? Wenn Sie es nicht wissen: Schicken Sie mir eine Woche Login-Zeiten. Ich zeige Ihnen im Prozess-Check das Protokoll dahinter.
