Drei Automatisierungen, die Erfolg meldeten und nichts taten

Über gescheiterte Automatisierung wird selten geschrieben, und wenn, dann über die spektakuläre Sorte: das System, das abstürzt, das Skript, das Daten löscht. Die teurere Sorte ist unauffälliger. Sie läuft weiter, meldet Erfolg und tut nichts.

Wir haben davon in den letzten Wochen drei Fälle im eigenen Haus gefunden. Alle drei liefen über Monate. Alle drei standen in der Überwachung auf grün. Weil das Muster übertragbar ist, steht es hier — einschließlich der Frage, warum es niemandem auffiel.

Fall 1: Der Workflow, der nur seinen Wecker ausführte

Ein Automatisierungslauf sollte werktäglich Artikel aus einem Verzeichnis abholen und als geplante Beiträge veröffentlichen. Er lief. Jeden Werktag. Und meldete jeden Lauf als erfolgreich.

Tatsächlich führte er seit dreieinhalb Monaten ausschließlich seinen Zeitauslöser aus. Zwei Ursachen lagen übereinander: Ein Baustein war umbenannt worden, ohne dass die Verbindung zum nächsten Schritt mitgezogen wurde — der Auslöser feuerte also ins Leere. Und ein Hilfsskript, das die Dateien überhaupt erst bereitstellt, hatte eine Positivliste erlaubter Dateinamen, in der das Muster für Artikel schlicht fehlte. Die Dateien kamen also gar nicht erst an.

Beide Änderungen entstanden innerhalb von rund vierundzwanzig Stunden. Drei Artikel sind nie erschienen.

Fall 2: Die Reparatur, die nichts reparierte

Der zweite Fall ist der lehrreichere, weil er aus einer Verbesserung entstand.

Eine Prüfung hatte ergeben, dass in sieben Tagen kein einziger Handlungsaufruf in unseren Beiträgen gelandet war — ein erkennbares Loch im Kontaktweg. Daraufhin wurde ein Baustein gebaut, der diesen Aufruf automatisch ergänzt. Er wurde gebaut, getestet und in Betrieb genommen.

Nur wurde das Ergebnis nie versendet. Der Baustein, der die Veröffentlichung vornimmt, kannte für diesen Inhalt gar kein Feld — es wurde schlicht nicht mitgeschickt. Und der neue Baustein legte sein Ergebnis unter einem Namen ab, den der nachfolgende Schritt nicht liest. Zwei unabhängige Fehler, die sich gegenseitig verdeckten.

Ergebnis: Die Reparatur eines Lochs lief dreieinhalb Monate, ohne das Loch zu schließen. Die ursprüngliche Prüfung, die den Anlass gab, wurde nie wiederholt.

Fall 3: Drei Maschinen, die nichts voneinander wissen

Der dritte Fall ist kein Defekt, sondern ein Strukturproblem. Bei uns liefen drei Veröffentlichungswege nebeneinander: ein zugekaufter Dienst für Blogartikel mit angeschlossener Weiterverteilung, eine eigene Automatisierung für Beiträge aus einem Redaktionskalender, und eine dritte Strecke für Kontaktstrecken.

Zwei davon bespielen dieselben Konten. Keine der drei kennt die anderen. Es gibt keine gemeinsame Sicht darauf, was an einem Tag nach draußen geht. Das fällt nicht als Fehler auf — es fällt als Gefühl auf, dass man den Überblick verloren hat.

Die unangenehmste Zahl in diesem Zusammenhang betraf nicht die Technik: Die Kontaktstrecke war fertig gebaut, funktionierte einwandfrei — und enthielt genau einen Kontakt, nämlich den Testeintrag. Nicht wegen eines Fehlers, sondern weil in den veröffentlichten Materialien schlicht kein Verweis darauf stand. Die Infrastruktur war der Reichweite um Monate voraus.

Was diese drei Fälle gemeinsam haben

In allen drei Fällen war der Status grün. Und in allen drei Fällen war das korrekt: Kein Schritt hatte einen Fehler geworfen.

Darin liegt der Kern. Ein Erfolgsstatus bedeutet in den meisten Automatisierungswerkzeugen „kein Fehler aufgetreten” — nicht „das Gewünschte ist passiert”. Ein Ablauf, dessen Erfolgsfall auch das Nichtstun einschließt, ist mit einer Statusüberwachung grundsätzlich nicht zu prüfen. Er braucht eine Prüfung auf das Ergebnis.

Der Unterschied lässt sich in zwei Fragen fassen:

• Negativprüfung: „Ist etwas schiefgegangen?” — schweigt bei allen drei Fällen.
• Positivprüfung: „Ist heute tatsächlich das erschienen, was fällig war?” — schlägt bei allen drei sofort an.

Was wir daraus gebaut haben

Drei Konsequenzen, die sich auf beliebige Automatisierung übertragen lassen:

Erstens: Jede Automatisierung mit Außenwirkung bekommt eine Positivprüfung. Sie läuft zeitversetzt nach dem eigentlichen Ablauf, prüft das erwartete Ergebnis am Zielsystem und meldet nur, wenn es fehlt. Bei Erfolg schweigt sie — sonst gewöhnt man sich an die Meldungen und liest sie nicht mehr.

Zweitens: Die Prüfung schaut auch auf die Konfiguration, nicht nur auf den Lauf. Das klingt übertrieben, hat aber einen konkreten Grund: In Fall 2 wird der abgeschickte Inhalt gar nicht protokolliert. Aus „die Gegenstelle hat angenommen” folgt also nicht, dass das Richtige ankam. Nur ein Blick in den ausgerollten Stand schließt diese Lücke — und schlägt an, wenn eine spätere Bearbeitung den Fix wieder herausnimmt.

Drittens: Wer ein Loch schließt, prüft am Zielsystem nach. Das ist die eigentliche Lehre aus Fall 2. Eine Reparatur, deren Wirkung niemand dort kontrolliert, wo sie ankommen soll, ist keine Reparatur — sie ist eine zweite Fehlerquelle, die zusätzlich noch das Gefühl erzeugt, das Problem sei erledigt.

Der unbequeme Teil

Diese drei Fälle sind über Monate gelaufen, in einem Haus, in dem Automatisierung zum Handwerk gehört und in dem es an Überwachung nicht mangelt. Es lag nicht an fehlendem Können und nicht an fehlenden Werkzeugen. Es lag daran, dass die Überwachung die falsche Frage gestellt hat.

Wenn Sie eine laufende Automatisierung haben, von der Sie annehmen, dass sie funktioniert: Prüfen Sie einmal nicht ihren Status, sondern ihr Ergebnis. Nicht den Lauf, sondern das Zielsystem. Die Erfahrung legt nahe, dass die Trefferquote dieser Übung unangenehm hoch ist.

Quellen

Eigene Befunde aus dem Betrieb, dokumentiert am 03.08.2026 (Fall 1 und Fall 3) sowie am 15.08.2026 (Fall 2). Alle drei Fälle sind inzwischen behoben beziehungsweise in Bearbeitung; die beschriebenen Prüfmechanismen laufen produktiv. Zeitangaben und Zeiträume stammen aus den Ausführungsprotokollen der betroffenen Abläufe.

Erstellt mit KI-Unterstützung, fachlich geprüft und redaktionell verantwortet von Achim Karpf.