Fehler 429 in Power Automate: Throttling verstehen und beheben

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.

Was verursacht den Fehler 429 in Power Automate?

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.

Welche Grenzwerte sollten Sie im Blick haben?

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.

Wie senken Sie die Parallelität richtig?

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": 15
8 }
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": 5
19 }
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.

Wie stellen Sie die Wiederholungsrichtlinie ein?

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.

Wie vermeiden Filter und Batching das Throttling dauerhaft?

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:

  1. Datenoperationen statt Schleife. „Array filtern", „Auswählen" und „Verbinden" verarbeiten die gesamte Liste in je einer Aktion.
  2. Batchanforderungen. Unterstützt der Connector sie, bündeln Sie mehrere Schreibvorgänge in einem einzigen Aufruf.
  3. Untergeordnete Flows. Sie verteilen die Last und halten das Burst-Limit je Flow ein.

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.

Typische Fehler und Ursachen

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.

Häufige Fragen zu Power Automate Throttling (429)

Warum bekomme ich 429-Fehler, obwohl mein tägliches Aktionslimit nicht erreicht ist?

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.

Hilft ein teurerer Lizenzplan gegen 429-Fehler?

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.

Was ist der Unterschied zwischen Aktions-Burst-Limit und Connector-Drosselung?

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.

Kann ich 429-Fehler durch automatische Wiederholungsversuche umgehen?

Nein, denn Wiederholungen zählen selbst gegen die Limits. Sie überbrücken kurze Spitzen. Dauerhaft hilft nur, die Zahl der Anfragen zu senken.

Simon Glowik, Gründer von NordFlux
Über den Autor

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

  • Microsoft zertifiziert — PL-900 und AZ-900
  • UiPath zertifiziert — Automation Developer Associate
Alle Beiträge
Weiterlesen

Verwandte Anleitungen

Kostenlose Erstanalyse

Fehler 429: Throttling bremst Ihren Flow im Dauerbetrieb

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.

Power Automate Beratung

  • Performance-Tuning gegen wiederkehrende 429-Fehler
  • Batching-Strategie für hohe Datenvolumen ohne Ausfallrisiko
  • Skalierungsplanung, bevor Wachstum zum Flaschenhals wird