Wer überwacht Ihre Automatisierungen? In den meisten Firmen: niemand.

Wer überwacht Ihre Automatisierungen? In den meisten Firmen: niemand.

Letzten Mittwoch um 14:30 Uhr hörte bei einem Kunden ein Make-Szenario auf zu laufen. Es war jenes Szenario, das eingehende Bestellungen aus dem Webshop in das ERP überträgt. Eine OAuth-Verbindung war abgelaufen, Make markierte den Lauf als "Failed" und stoppte. Im Dashboard stand das. Nur sah niemand ins Dashboard.

Der Ausfall fiel am Freitag um 16:50 Uhr auf, als ein Kunde anrief und nach seiner Auftragsbestätigung fragte. In der Zwischenzeit waren 47 Bestellungen aufgelaufen, davon 18 mit Versandfristen, die jetzt nicht mehr zu halten waren.

Das ist kein extremer Fall. Das ist der Standardfall, den ich in den meisten Firmen sehe, sobald man ehrlich nachfragt: Workflows laufen, bis sie nicht mehr laufen, und dann passiert eine Weile nichts, bis ein Mensch zufällig stolpert.

Monitoring ist der dunkle Punkt der Automatisierung

In den ersten Wochen eines Projekts geht es darum, ob ein Workflow überhaupt funktioniert. Werden die Daten richtig übergeben? Greifen die Filter? Stimmt das Mapping?

Das sind sinnvolle Fragen. Sie hören aber auf, wenn der Workflow zum ersten Mal sauber durchläuft. Ab dem Moment lautet die Frage nicht mehr "funktioniert das?", sondern "wer merkt es, wenn es nicht mehr funktioniert?".

Diese zweite Frage stellt sich kaum jemand. Sie wird stillschweigend mit "die Plattform" beantwortet, was ungefähr so präzise ist, als würde man fragen, wer den Server betreibt, und antworten "die Steckdose".

Drei Ausfallarten, die jeder kennt und keiner überwacht

Drei Fehlerbilder dominieren in produktiven Workflows, und alle drei sind ohne Monitoring schwer zu bemerken.

Stille Authentifizierungsfehler. OAuth-Tokens laufen ab. Refresh schlägt fehl, weil ein Mitarbeiter sein Passwort geändert hat oder ein Admin eine Berechtigung entzogen hat. Der Workflow stoppt. Er crasht nicht, er ruft nicht. Er wartet auf einen Auslöser, der nie kommt, weil die Verbindung kaputt ist.

Erfolgreiche Läufe mit kaputten Daten. Ein API-Call gibt einen leeren Datensatz zurück, der Workflow läuft trotzdem durch und schreibt einen leeren Eintrag weiter. Statistiken zeigen "Erfolg", die Daten zeigen Unsinn. Das Erfolgskriterium lautet "Lauf abgeschlossen", nicht "Daten sinnvoll".

Eingebrochene Mengen. Statt täglich 200 Aufträge laufen plötzlich nur noch 80. Die Schritte sind grün. Der Trigger feuert seltener als sonst, weil die vorgelagerte API ein Limit erreicht hat oder ein Filter zu eng greift. Niemand merkt es, weil es keinen Soll-Wert gibt, gegen den verglichen wird.

Was Monitoring wirklich heißt

Monitoring ist nicht "im Dashboard nachsehen". Im Dashboard nachsehen ist Erinnerungsarbeit, die zuverlässig vergessen wird, sobald jemand mehrere Themen parallel hat.

Sinnvolles Monitoring bedeutet, dass das System sich von selbst meldet, wenn etwas schiefläuft. Dabei sind drei Schichten zu trennen, die in der Praxis oft vermischt werden.

Liveness. Läuft die Plattform überhaupt? Antwortet n8n? Ist Make erreichbar? Die einfachste Stufe, gelöst von Diensten wie StatusCake oder UptimeRobot für ein paar Euro im Monat.

Workflow-Health. Laufen die einzelnen Automatisierungen erfolgreich durch? Wie sieht die Erfolgsquote der letzten 24 Stunden aus? Die meisten Plattformen haben dafür ein internes Log, aber niemand liest hinein. Hier braucht es einen Mechanismus, der Fehler aktiv pusht, statt darauf zu warten, dass jemand schaut.

Business-Kennzahlen. Wie viele Bestellungen hat das System heute verarbeitet, im Vergleich zum gleichen Wochentag der Vorwoche? Wie viele Rechnungen sind rausgegangen? Diese Schicht ist die wichtigste, weil sie auch dann anschlägt, wenn der Workflow technisch grün ist, fachlich aber Unsinn macht.

Die meisten Firmen haben null von drei.

Eine pragmatische Einrichtung in zwei Stunden

Die gute Nachricht: Monitoring für Automatisierungen muss nicht teuer oder kompliziert sein. Eine vernünftige Mindestausstattung lässt sich an einem Vormittag aufbauen.

Heartbeat-Mechanismus. Jeder produktive Workflow schickt am Ende eines erfolgreichen Laufs einen Ping an einen externen Dienst. healthchecks.io oder Cronitor reichen. Bleibt der Ping aus, schlägt der Dienst Alarm. Das fängt sowohl "Plattform tot" als auch "Workflow stoppt" mit demselben Mechanismus.

Fehler-Alerting in einen eigenen Slack-Kanal. Direkt in n8n oder Make einen "On Error"-Pfad einbauen, der eine Nachricht in einen dedizierten Slack-Kanal schickt. Nicht in den Hauptkanal, sondern in ein eigenes Postfach für Maschinenmeldungen, das zweimal täglich gesichtet wird.

Tagesreport. Einmal am Tag eine kompakte Zusammenfassung: Wie viele Läufe waren erfolgreich, wie viele sind gescheitert, gibt es Auffälligkeiten in der Verarbeitungsmenge? Das schreibt ein eigener Workflow, der die internen Logs liest und in einer Mail oder einem Slack-Post zusammenfasst.

Mit diesen drei Bausteinen liegt das Niveau über dem, was die meisten Firmen heute haben, und der Aufwand bleibt unter zwei Stunden Einrichtung plus etwa zehn Minuten pro Workflow.

Wo es schwer wird

So weit, so machbar. Schwieriger wird es, sobald die Anzahl der Workflows steigt und das tägliche Rauschen zu groß wird.

Wer zwanzig Workflows hat und jeden Fehler einzeln in Slack landen lässt, hat nach drei Wochen einen Kanal, in den niemand mehr schaut. Hier braucht es Aggregation: Fehler nach Workflow-Familie gruppieren, wiederholte Fehler zusammenfassen, klare Schwellwerte definieren, ab wann ein Mensch eingreifen soll.

An dieser Stelle scheitern viele Setups. Die ersten drei Wochen funktionieren. Dann werden die Alarme stumpf. Das ist der Punkt, an dem ein einfaches Tool wie healthchecks.io nicht mehr reicht und Werkzeuge wie Better Stack, Sentry mit Webhook-Anbindung oder ein selbstgehostetes Grafana mit Loki sinnvoll werden.

Die Frage, die niemand stellt

Wer heute zwanzig produktive Workflows hat, sollte sich folgendes fragen: Wenn morgen früh um drei Uhr einer davon stoppt, wann erfahre ich das?

Lautet die Antwort "wenn jemand stolpert", ist das kein Monitoring, sondern Glück. Glück ist eine schlechte Strategie für Geschäftsprozesse.

Lautet die Antwort "wenn die Plattform einen E-Mail-Alarm sendet", verlassen Sie sich auf eine Standardfunktion, die in der Praxis oft nicht greift, weil sie nicht alle Fehlerklassen abdeckt.

Lautet die Antwort "wir haben ein Dashboard, in das wir morgens schauen", funktioniert das so lange, wie jemand morgens schaut und die Disziplin nicht abhandenkommt.

Eine vernünftige Antwort lautet: "Wir bekommen innerhalb von 15 Minuten eine Push-Benachrichtigung, weil unser Heartbeat ausgeblieben ist, und ein Tagesreport meldet zusätzlich Auffälligkeiten."

Diese Antwort ist mit überschaubarem Aufwand erreichbar. Sie wird in der Praxis fast nie umgesetzt, weil Monitoring weniger spannend wirkt als der nächste Workflow. Bis es einen Ausfall gibt, der teurer ist, als zwei Jahre lückenloses Alerting gekostet hätten.

Wer wissen möchte, ob die eigenen Workflows angemessen überwacht werden, bekommt im kostenlosen Automations-Check in etwa 30 Minuten ein klares Bild.