Die Automatisierung läuft, die Abteilung hat Zeit gewonnen, das Projekt gilt als abgeschlossen. Wenige Monate später kommt keine Meldung mehr an, Aufträge fehlen im System, und niemand weiß, seit wann. Die Ursache ist selten ein Programmierfehler. Meist ist ein Zugang abgelaufen, die Person, der der Ablauf gehört, hat das Unternehmen verlassen, oder der Ablauf wurde vom Werkzeug abgeschaltet, nachdem er lange nur Fehler erzeugt hat.
Dieser Beitrag beschreibt, was es heißt, automatisierte Prozesse zu überwachen und zu warten, und wer das in einem Betrieb ohne IT-Leitung übernimmt. Er stützt sich auf die Dokumentation von Microsoft, n8n und Make (Stand Oktober 2026, jeweils mit Link). Wie Sie zuvor prüfen, ob ein Prozess überhaupt reif für die Automatisierung ist, steht in Woran erkenne ich, ob ein Prozess automatisierungsreif ist?.
Automatisierte Prozesse überwachen: was Werkzeuge von selbst tun und was nicht
Alle drei gängigen Werkzeuge melden Fehler, aber nur an die Stellen, die Sie eingerichtet haben. Und sie schalten Abläufe ab, wenn Fehler anhalten. Beides kennen Sie vorher nur, wenn Sie in die Dokumentation sehen.
Power Automate. Laut Seite zu den Grenzwerten wird ein Cloud-Flow ausgeschaltet, dessen Auslöser oder Aktionen dauerhaft scheitern; die Tabelle nennt dafür 14 Tage. Ein Flow, der in 90 Tagen nicht ausgelöst wird, kann ebenfalls ausgeschaltet werden. Von dieser Aussetzung ausgenommen sind laut Tabelle Abläufe, deren Besitzer eine Premium-Lizenz hat oder die eine Process-Lizenz (je Flow) haben. Besitzer und Mitbesitzer werden laut Seite 30 Tage vorher benachrichtigt und können den Flow wieder einschalten. Das setzt voraus, dass diese Mails jemand liest.
n8n. Laut Dokumentation zur Fehlerbehandlung legen Sie in den Einstellungen eines Ablaufs einen Fehlerablauf fest. Er muss mit dem Baustein „Error Trigger“ beginnen, läuft, wenn eine Ausführung scheitert, und kann zum Beispiel eine E-Mail oder eine Slack-Meldung schicken. Ein Fehlerablauf kann für mehrere Abläufe dienen. Einschränkungen nennt die Seite zum Error Trigger: Er lässt sich nicht testen, indem Sie einen Ablauf von Hand starten, er läuft nur bei automatisch gestarteten Abläufen. Und wenn schon der Auslöser scheitert, liefert er weniger Angaben zur Ausführung. Welche Meldung hinausgeht und wohin, bestimmt der Fehlerablauf, den Sie selbst einrichten.
Make. Laut Hilfeseite zu Fehlern und Warnungen schickt Make eine E-Mail, wenn ein Fehler von keinem Fehlerbehandler abgefangen wird, und noch eine, wenn ein Szenario wegen wiederholter Fehler abgeschaltet wird. Der Zeitplan eines Szenarios wird deaktiviert, wenn es mehrfach hintereinander mit Fehler endet. Laut Übersicht zur Fehlerbehandlung liegt der Standard bei drei Fehlern in Folge; bei Szenarien mit Sofort-Auslöser (Webhook) und bei bestimmten Fehlerarten, darunter Fehler bei der Kontoprüfung (AccountValidationError), greift die Abschaltung sofort.
Die Gemeinsamkeit: Das Werkzeug bemerkt den Ausfall, aber Konsequenzen zieht es nur für sich selbst, nämlich es hört auf. Dass die Arbeit trotzdem erledigt werden muss, merkt nur ein Mensch.
Wohin die Meldung geht, entscheidet über den Ausfall
Eine Fehlermeldung an die Adresse der Person, die den Ablauf gebaut hat, ist ein Einzelpunkt: Ist sie im Urlaub, krank oder weg, liest sie niemand. Legen Sie pro Ablauf fest:
- Empfänger. Ein gemeinsames Postfach oder ein Kanal, den mindestens zwei Personen lesen.
- Schwelle. Meldet jeder einzelne Fehler, oder erst der dritte in Folge? Zu viele Meldungen werden überlesen, zu wenige lassen den Ablauf tagelang liegen.
- Reaktionszeit. Bis wann muss jemand gesehen haben, dass ein Lauf scheiterte? Bei Rechnungen, Aufträgen und Terminen ist das ein Arbeitstag, bei einem Newsletter-Abgleich vielleicht eine Woche.
- Auffangnetz. Was geschieht mit Vorgängen, die während des Ausfalls anfielen? Make hält Läufe auf Wunsch als „unvollständige Ausführungen“ vor; laut Übersicht zur Fehlerbehandlung ist das eine manuelle Warteschlange, aus der Sie nach der Behebung weitermachen. Bei anderen Werkzeugen gehört diese Warteschlange zum Entwurf des Ablaufs. Wie ein Ablauf mit unklarem Ergebnis umgeht, steht in Unklares Ergebnis: wiederholen, nachschauen oder Mensch?.
Was „Wartung“ bei einer Automatisierung bedeutet
Eine Automatisierung ist kein Gerät, das man einmal aufstellt. Sie hängt an Programmen, die sich ändern, und an Zugängen, die ablaufen. Sinnvoll ist ein fester, kleiner Rhythmus.
Laufend: Fehler lesen. Jemand sieht nach, welche Fehler gemeldet wurden und ob sie sich häufen. Tritt derselbe Fehler immer wieder auf, ist der Ablauf anzupassen, nicht der Fehler wegzuklicken.
Monatlich: Updates. Wer n8n selbst betreibt, aktualisiert laut Dokumentation möglichst oft, mindestens einmal im Monat, prüft vorher die Versionshinweise auf Breaking Changes und testet das Update auf einer Testinstanz. Für Version 3.0 kündigt n8n auf der Seite zu den Breaking Changes an, dass selbst betriebenes n8n nur noch als Docker-Installation unterstützt wird, nicht mehr per npm, und dass einige alte Bausteine entfallen. Ein Migrationsbericht in den Einstellungen listet die betroffenen Abläufe. Wer die Hinweise nicht liest, wird vom Update überrascht.
Laufend: Daten aufräumen. Auch Ausführungsdaten kosten Platz. Laut n8n-Dokumentation ist das Löschen alter Ausführungen standardmäßig aktiv: nach 14 Tagen (336 Stunden) oder wenn mehr als 10.000 Ausführungen vorliegen. Das heißt auch: Was ein Fehlerprotokoll von vor drei Wochen sagte, ist gelöscht, falls es niemand gesichert hat. Wer Nachweise braucht, etwa für Buchhaltungsabläufe, regelt die Aufbewahrung selbst und nicht über das Standardverhalten.
Mindestens jährlich: Zugangsdaten. Jede Verbindung zu einem Fremdsystem ist ein Schlüssel, der abläuft oder widerrufen wird. Laut Microsoft Learn ist die Laufzeit eines Client-Geheimnisses einer App-Registrierung in Microsoft Entra auf höchstens zwei Jahre (24 Monate) begrenzt, Microsoft empfiehlt weniger als zwölf Monate. Läuft das Geheimnis ab, scheitert jeder Ablauf, der damit arbeitet, und zwar an einem Tag, den niemand ausgesucht hat. Auch Make nennt abgelaufene API-Schlüssel und widerrufene Zugriffe nach Rechteänderungen als typische Ursache für Fehler. Führen Sie deshalb eine Liste: welcher Zugang, wofür, wer hat ihn angelegt, wann läuft er ab.
Bei jeder Änderung am Zielsystem: Ablauf prüfen. Ein neues Pflichtfeld im CRM, ein geänderter Dateiname im Export, ein Update des ERP: Jede Änderung, die ein angebundenes System betrifft, ist eine Änderung am Ablauf. Das gehört in den Änderungsprozess der Fachabteilung, nicht ans Ende der Kette. Wie Sie solche Änderungen bei Microsoft im Blick behalten, steht in Microsoft 365 Message Center: Änderungen im Blick behalten.
Wer vertritt, wenn der Ersteller geht?
Die häufigste Lücke ist keine technische. Ein Ablauf hängt am Konto einer Person: Sie ist Besitzerin, ihre Zugangsdaten stecken in den Verbindungen, ihre Mailadresse bekommt die Fehlermeldungen. Verlässt sie das Unternehmen, bleibt ein Ablauf zurück, der läuft, bis eine der drei Bedingungen kippt.
Microsoft beschreibt den Fall in Manage orphaned flows when the owner leaves the organization: Ein verwaister Flow ist einer ohne gültigen Besitzer, und er kann scheitern, wenn er Verbindungen nutzt, die an das Konto der gegangenen Person gebunden sind. Administratoren finden solche Flows im Power Platform Admin Center unter Ressourcen und Flows und tragen dort neue Mitbesitzer ein; für viele Flows gibt es PowerShell-Befehle.
Besser ist, es gar nicht so weit kommen zu lassen. Laut Anleitung zum Teilen von Cloud-Flows können Sie weitere Besitzer hinzufügen, auch Gruppen; wer Besitzer ist, kann Eigenschaften ändern, Zugangsdaten einer Verbindung aktualisieren und den Verlauf einsehen. Die Seite weist aber auch darauf hin, dass Besitzer die Zugangsdaten einer Verbindung nicht ändern können, die ein anderer Besitzer angelegt hat. Ein zweiter Name im Besitzerfeld reicht also nicht: Prüfen Sie, wessen Konto hinter jeder Verbindung steht.
Eine Seite pro Ablauf genügt als Grundlage:
- Zweck in einem Satz und welche Systeme beteiligt sind
- Besitzer und Vertretung, beide namentlich
- Wohin Fehlermeldungen gehen und wer sie liest
- Welche Zugänge der Ablauf nutzt, wer sie angelegt hat, wann sie ablaufen
- Was von Hand zu tun ist, wenn der Ablauf steht
- Wo die Beschreibung des Ablaufs außerhalb des Werkzeugs liegt
Dieselbe Disziplin kennen Sie von „Wir dokumentieren später“ als Betriebsrisiko, und sie gilt bei einem Wechsel des Dienstleisters genauso (Was nach einem Dienstleisterwechsel zuerst zu prüfen ist).
Selbst übernehmen oder betreuen lassen
Prüfen Sie ehrlich, wer in Ihrem Haus die Punkte oben tragen kann: Fehler lesen, Updates einspielen, Zugänge verlängern, bei Änderungen im Zielsystem den Ablauf anpassen. Bei zwei, drei einfachen Abläufen in Microsoft 365 ist das nebenbei zu schaffen. Je mehr Systeme, je mehr Geld oder Kundendaten durch die Abläufe laufen und je weniger Personen sie verstehen, desto eher lohnt es sich, den Betrieb festzulegen, sei es im Haus mit klarer Zuständigkeit, sei es bei einem Dienstleister.
Die Wahl des Werkzeugs ändert daran wenig: Ob Power Automate oder n8n oder n8n, Make und Zapier, jedes bringt eigene Wege für Meldung und Abschaltung mit, und keines nimmt Ihnen die Zuständigkeit ab. Was der Betrieb kostet, hängt vom Umfang ab; die Staffel für Aufbau und Betrieb steht in Was Prozessautomatisierung wirklich kostet.
Wenn der Betrieb zum Engpass wird
Wenn Sie nicht wissen, welche Automatisierungen im Unternehmen laufen, wem sie gehören und was passiert, wenn eine ausfällt, ist das ein Fall für die Technische Begleitung von 01PC, ab 1.900 € netto im Monat. Sie ordnet Dienstleister ein, zeichnet Entscheidungen gegen und behält die Systemlandschaft im Blick. Sollen einzelne Abläufe gebaut oder übernommen und betrieben werden, ist das die Prozessautomatisierung: Aufnahme 3.900 € netto, erste Strecke ab 7.500 € netto, Betrieb ab 390 € netto im Monat. Der Betrieb ist optional; ohne Betriebsvertrag übernehmen Sie selbst.