Power Automate: Run-Verlauf lesen und Fehler finden
So lesen Sie den Ausführungsverlauf in Power Automate richtig und finden die Ursache einer fehlgeschlagenen Ausführung.
Warum Power Automate den Fehler 429 wirft und wie Sie Throttling durch Parallelitätssteuerung und Batching gezielt beheben.
Der Fehler 429 („Too Many Requests") bedeutet, dass ein Flow mehr Anfragen gesendet hat, als der angesprochene Dienst in seinem Zeitfenster zulässt. Weitere Aufrufe werden dann gedrosselt.
Der Fehlertext nennt in der Regel die Wartezeit, etwa „Rate limit is exceeded. Try again in 27 seconds". Diese Drosselung kommt fast immer vom Connector, nicht von Ihrem Tageskontingent.
Dieser Beitrag zeigt die relevanten Grenzwerte, die passenden Einstellungen im Code-Editor und die Reihenfolge, in der Sie vorgehen.
Ursache ist ein überschrittenes Zeitfenster auf der Seite des Dienstes, den Ihr Flow aufruft. Jeder Connector bringt eigene Grenzwerte mit, unabhängig von Ihrer Lizenz.
Microsoft beschreibt das in Plattformgrenzen verstehen und Drosselung vermeiden. Der Dienst antwortet mit Fehlercode 429 und einem Hinweis auf die Wartezeit.
Drei Auslöser dominieren in der Praxis. Erstens Schleifen mit vielen Iterationen. Zweitens mehrere gleichzeitig laufende Instanzen desselben Flows. Drittens eine Verbindung, die sich mehrere Flows teilen.
Der letzte Punkt wird oft übersehen. Das SharePoint-Limit gilt pro Verbindung über alle Flows hinweg, nicht pro Flow. Wer eine SharePoint-Umgebung migriert, sollte das schon bei der Aufteilung der Dienstkonten berücksichtigen.
Vier Ebenen erzeugen unabhängig voneinander einen 429er, und nur eine davon hängt an der Lizenz. Die folgenden Werte stammen aus der Herstellerdokumentation.
Grenze | Wert | Bezugsgröße
Grenze: SharePoint-Connector · Wert: 600 Aufrufe je 60 Sekunden · Bezugsgröße: je Verbindung, über alle Flows hinweg
Grenze: Aktions-Burst-Limit · Wert: 100.000 Aktionen in fünf Minuten · Bezugsgröße: je Flow
Grenze: Dataverse, Anzahl Anfragen · Wert: 6.000 im gleitenden Fünf-Minuten-Fenster · Bezugsgröße: je Benutzer und Webserver
Grenze: Dataverse, Ausführungszeit · Wert: 1.200 Sekunden im selben Fenster · Bezugsgröße: je Benutzer und Webserver
Grenze: Dataverse, gleichzeitige Anfragen · Wert: 52 · Bezugsgröße: je Benutzer
Grenze: Power-Platform-Anfragen · Wert: je nach Lizenzplan · Bezugsgröße: alle Flows eines Benutzers in 24 Stunden
Quellen: Power-Automate-Lizenzierungs-FAQ, Plattformgrenzen und Service Protection API Limits.
Wichtig für die Fehlersuche: Erfolgreiche und fehlgeschlagene Aktionen zählen beide. Wiederholungsversuche und zusätzliche Anfragen durch Paginierung ebenfalls. Nur übersprungene Aktionen zählen nicht.
Der schnellste Hebel ist der Parallelitätsgrad, und er sitzt an zwei verschiedenen Stellen. Der Trigger steuert, wie viele Flow-Läufe gleichzeitig starten. Die Schleife steuert, wie viele Elemente gleichzeitig verarbeitet werden.
Stellschraube | Wertebereich | Standard | Besonderheit
Stellschraube: Trigger-Parallelität · Wertebereich: 1 bis 100 · Standard: aus, bei Aktivierung 25 · Besonderheit: nicht rückgängig zu machen
Stellschraube: Wartende Läufe · Wertebereich: 10 plus Parallelitätsgrad · Standard: entfällt bei ausgeschalteter Steuerung · Besonderheit: darüber weist der Trigger ab
Stellschraube: Schleifen-Parallelität · Wertebereich: 1 bis 50 · Standard: 1 · Besonderheit: wirkt nur auf oberster Ebene
Stellschraube: „SplitOn"-Elemente · Wertebereich: 100 bei aktiver Trigger-Parallelität · Standard: 5.000 bzw. 100.000 · Besonderheit: Debatching bricht stark ein
Quelle: Grenzwerte für Cloud-Flows.
Beide Werte lassen sich im Designer über „Einstellungen" und „Nebenläufigkeitssteuerung" setzen. Im Code-Editor sehen sie so aus:
1{2 "Wenn_ein_Element_erstellt_wird": {3 "type": "ApiConnection",4 "runtimeConfiguration": {5 "concurrency": {6 "runs": 5,7 "maximumWaitingRuns": 158 }9 }10 },11 "Auf_alle_anwenden": {12 "type": "Foreach",13 "foreach": "@body('Elemente_abrufen')?['value']",14 "actions": {},15 "runAfter": {},16 "runtimeConfiguration": {17 "concurrency": {18 "repetitions": 519 }20 }21 }22}runs begrenzt gleichzeitige Flow-Läufe, repetitions gleichzeitige Schleifendurchläufe. Bei runs: 5 liegt die Obergrenze wartender Läufe bei 15, also 10 plus 5.
Prüfen Sie nach der Änderung die Laufhistorie über 24 Stunden. Verschwinden die 429er und bleibt die Laufzeit vertretbar, war der Wert richtig gewählt.
Sie setzen die Wiederholungsrichtlinie je Aktion, im Designer unter „Einstellungen" und „Wiederholungsrichtlinie" oder im Code-Editor über das Objekt retryPolicy. Sie ist die zweite Verteidigungslinie, nie die erste.
Standardmäßig wiederholt Power Automate eine fehlgeschlagene Aktion bis zu vier Mal. Die Abstände wachsen exponentiell, skalieren um 7,5 Sekunden und liegen zwischen 5 und 45 Sekunden. Ausgelöst wird das bei den Statuscodes 408, 429 und 5xx.
Für gedrosselte Connectoren sind längere Abstände oft sinnvoller als mehr Versuche:
1{2 "Element_erstellen": {3 "type": "ApiConnection",4 "inputs": {5 "retryPolicy": {6 "type": "exponential",7 "count": 6,8 "interval": "PT20S",9 "minimumInterval": "PT10S",10 "maximumInterval": "PT2M"11 }12 },13 "runAfter": {}14 }15}Die Werte folgen dem ISO-8601-Format, PT20S sind 20 Sekunden. count erlaubt 1 bis 90 Versuche. Die Referenz steht unter Fehlerbehandlung und Wiederholungsrichtlinien.
Bedenken Sie die Kosten: Jeder Wiederholungsversuch zählt als eigene Aktion gegen Ihr Tageskontingent.
Die stabilste Lösung ist, weniger Anfragen zu erzeugen. Was der Server bereits gefiltert liefert, muss der Flow nicht Zeile für Zeile prüfen.
Bei SharePoint übernimmt das die OData-Filterabfrage im Feld „Filter Query" der Aktion „Elemente abrufen":
1Status eq 'Offen' and Modified ge '2026-08-01T00:00:00Z'Leerzeichen in Spaltennamen ersetzen Sie durch _x0020_, etwa Start_x0020_Date. Ergänzend begrenzt „Top Count" die Trefferzahl.
Drei weitere Muster senken die Aufrufzahl deutlich:
Zu Punkt 2 ein Hinweis aus der Dataverse-Dokumentation: Ein Batch umgeht zwar das Limit für die Anzahl der Anfragen, läuft dafür aber leichter in das Limit für die Ausführungszeit.
Fünf Fehlerbilder treten bei 429-Meldungen regelmäßig auf, und alle fünf haben eine dokumentierte Ursache.
Der 429er tritt auf, obwohl das Tageslimit nicht erreicht ist. Ursache: Connector-Drosselung und tägliches Kontingent sind getrennte Mechanismen. Lösung: Den Connector identifizieren und dessen Zeitfenster entlasten. Quelle: Lizenzierungs-FAQ.
Ein zweiter Flow löst die Drosselung aus. Ursache: Das SharePoint-Limit von 600 Aufrufen je Minute gilt pro Verbindung, nicht pro Flow. Lösung: Getrennte Verbindungen oder Dienstkonten je Lastbereich verwenden. Quelle: Langsame Flows beheben.
Die Nebenläufigkeitssteuerung lässt sich nicht mehr abschalten. Ursache: Die Einstellung am Trigger ist unumkehrbar. Lösung: Trigger löschen und neu anlegen, oder die Steuerung von vornherein in einem untergeordneten Flow setzen. Quelle: Trigger optimieren.
Nach dem Einschalten der Trigger-Parallelität verarbeitet der Flow nur noch 100 Elemente. Ursache: Bei aktiver Trigger-Parallelität sinkt die „SplitOn"-Grenze von 5.000 beziehungsweise 100.000 auf 100. Lösung: Debatching und Trigger-Parallelität nicht kombinieren. Quelle: Grenzwerte für Cloud-Flows.
Mehr Wiederholungen verschlimmern die Lage. Ursache: Jeder Versuch zählt als Aktion und trifft dasselbe Zeitfenster erneut. Lösung: Abstände verlängern statt Versuche erhöhen und die Ursache im Flow-Design beheben. Quelle: Wiederholungsrichtlinien.
Wer wiederkehrendes Throttling grundsätzlich abstellen möchte, findet in der Power-Automate-Beratung von NordFlux Unterstützung bei Flow-Architektur, Lizenzwahl und Fehlersuche.
Weil Connector-Drosselung unabhängig vom Tageskontingent greift. SharePoint erlaubt 600 Aktionen je Minute und Verbindung. Dieses kurze Fenster reißen Sie auch bei niedrigem Tagesverbrauch.
Nur selten. Ein höherer Plan erhöht das tägliche Kontingent, nicht die Grenzwerte der Connectoren. Wirksamer sind Parallelität, Filterung und Flow-Design.
Das Burst-Limit ist plattformweit und liegt bei 100.000 Aktionen je Flow in fünf Minuten. Die Connector-Drosselung gilt je Dienst und variiert stark. Beide erzeugen denselben Fehlercode.
Nein, denn Wiederholungen zählen selbst gegen die Limits. Sie überbrücken kurze Spitzen. Dauerhaft hilft nur, die Zahl der Anfragen zu senken.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
So lesen Sie den Ausführungsverlauf in Power Automate richtig und finden die Ursache einer fehlgeschlagenen Ausführung.
Warum Power Automate Flows nach 14 Tagen Dauer-Throttling abschaltet, wie Sie das erkennen und den Flow wieder sauber aktivieren.
Was dynamischer Inhalt in Power Automate ist, wie Sie ihn einfügen und wo Einsteiger typische Stolperfallen vermeiden.
Grenzwerte für Parallelität und Aktionen pro Minute wirken abstrakt, bis ein produktiver Flow mitten im Tagesgeschäft mit Fehler 429 stehen bleibt. NordFlux plant Concurrency Control und Batching von Anfang an so, dass Ihre Flows auch bei wachsendem Datenvolumen stabil laufen. Im ersten Gespräch prüfen wir Ihre aktuellen Flows auf Throttling-Risiken.