Power Automate: Anfragelimits und Fehler 429

Ein Flow wird beim Import langsam und der Konnektor meldet Fehler 429. Der Administrator sieht in einer Tabelle 40 000 Anfragen, in einer anderen 200 000 und in der Betriebsstatistik nur achttausend. Eine zusätzliche Lizenz kann fehlende Tageskapazität lösen. Eine kurze Lastspitze gegen ein bestimmtes API behebt sie nicht automatisch.

Unterscheiden Sie Power-Platform-Anfragekontingente, vorübergehende Limitdurchsetzung und technischen Dienstschutz. „Limit“ bezeichnet hier weder dieselbe Messgröße noch dasselbe Zeitfenster oder dieselbe Abhilfe. Ein erfolgreicher Lauf oberhalb des offiziellen Kontingents belegt keine dauerhaft ausreichende Lizenzkapazität.

Inhaltlich geprüft am 21. Oktober 2026. Der Text behandelt Power-Automate-Cloudflows und ihre Aufrufe an Dataverse oder Konnektoren. Agent-Flows werden anders gemessen. Die Ausführung von Desktopflows selbst verbraucht laut aktueller Dokumentation keine Power Platform Requests. Die Beispiele sind eigene Berechnungen, keine gemessene Mandantenleistung.

Ein Flow-Lauf ist nicht eine Anfrage

Die Übersicht zu Anfragen und Zuteilungen umfasst Konnektor-API-Aufrufe, HTTP-Aktionen und integrierte Power-Automate-Aktionen wie Variableninitialisierung oder Compose. Erfolgreiche und fehlgeschlagene Aktionen, Wiederholungen und zusätzliche Paginierungsanfragen zählen. Zwanzig Schleifenelemente können denselben Schritt zwanzigmal ausführen. Auch Trigger und Steuerungsaktionen zählen: Laut FAQ ergeben ein Trigger und eine ausgeführte Aktion zwei gezählte Aktionen statt einer.

Beginnen Sie die Kapazitätsplanung daher nicht mit Laufzahlen. Ermitteln Sie tatsächlich ausgeführte zählende Aktionen je Pfad, Schleifendurchläufe, aktive Zweige und Wiederholungen. Eine übersprungene Aktion ist anders zu behandeln als eine tausendmal ausgeführte Schleifenaktion. Vergleichen Sie den Entwurf mit dem Laufverlauf statt nur mit der Blockzahl auf der Entwurfsfläche.

Microsoft erklärt außerdem, dass ein Power-Automate-Aufruf an Dataverse dabei nicht automatisch doppelt zählt, nur weil zwei Dienste beteiligt sind. Das macht nicht jede komplexe Integration zu einer einzigen Operation. Tatsächlich ausgelöste Zusatzschritte und relevante Operationen müssen nach ihren Regeln berücksichtigt werden.

Drei Ebenen von Limits

Die Cloudflow-Limits nennen auch Leistungsprofile und Betriebswerte. Übersetzen Sie diese nicht direkt in das vertragliche Kontingent eines konkreten Benutzers. Prüfen Sie zunächst, ob die Tabelle Zuteilungen, Übergangsdurchsetzung oder den Zielkonnektor beschreibt.

Eine weitere unabhängige Grenze in Power Automate sind laut Dokumentation 100 000 Anfragen in fünf Minuten, unabhängig von der Benutzerlizenz. Das ist nicht das deutlich niedrigere Dataverse-Standardlimit für API-Anfragen im gleichen Zeitraum. Es sind verschiedene Ebenen desselben Flows.

Warum bei Premium 40 000 und 200 000 stehen

Die aktuelle Zuteilungsdokumentation nennt ausdrücklich eine Übergangsphase für alle Organisationen. Für Premium und enthaltene Benutzerrechte wird währenddessen je Cloudflow begrenzt; das Zielmodell verwendet Benutzerkontingente. Process und ältere Per-Flow-Pläne bleiben auch danach Flowkapazität. Planen Sie nach dem offiziellen Recht statt nur nach einer aktuell großzügigeren beobachteten Grenze.

Ein Premium-Benutzer erhält damit nicht 40 000 plus 200 000 zusammen. Die Zahlen beschreiben andere Ebenen und Durchsetzungsphasen. Laut Microsoft beginnt die offizielle Durchsetzung frühestens sechs Monate nach allgemeiner Verfügbarkeit der Nutzungsberichte. Ohne bestätigten Meilenstein und Folgedatum gehört kein selbst geschätztes Übergangsende in die Projektplanung.

Enthaltene Power-Platform-Fähigkeiten bestimmter Microsoft-365-Pläne haben offiziell 6 000 Anfragen je 24 Stunden, nicht automatisch Premium-Rechte. Die Bezeichnung Microsoft 365 E5 allein ordnet einen Flow daher keinem beliebig hohen Power-Automate-Profil zu. Konnektornutzungsrechte und Kapazität sind verbundene, aber getrennte Prüfungen.

Wem wird der Verbrauch zugerechnet?

Die Lizenzierungs-FAQ für Power Automate unterscheidet automatisierte und geplante von manuellen Flows. Bei automatisierten und geplanten Flows zählen typischerweise Eigentümerlimits, bei manuellen etwa die des auslösenden Benutzers. Das in einer Verbindung gespeicherte Konto muss nicht die für das gesamte Kontingent entscheidende Identität sein.

Zählen Sie das Kontingent einer Person nicht je Umgebung erneut. Zwei Umgebungen ergeben keine zwei neuen Zuteilungen derselben Lizenz. Ebenso lassen sich freie Anfragen eines anderen Beschäftigten nicht ohne Weiteres in einen gemeinsamen Benutzerpool verschieben. Unterscheiden Sie mehrere passende Lizenzen einer Person von der Kapazität verschiedener Personen.

Nicht lizenzierte Identitäten, etwa Application Users, nutzen eine eigene Mandantenpool-Kategorie. Ein neuer Dienstprinzipal erzeugt keinen eigenen zusätzlichen Mandantenpool. Die Dokumentation nennt außerdem Fälle, in denen ein Dienstprinzipal-Flow Process, eine passende Flowgruppe oder die Limits eines designated licensed user statt dieses Pools nutzt. Ein Wechsel des Eigentümertyps erfordert deshalb eine neue Berechnung statt bloß der Entfernung eines Dienstkontopassworts.

Eigene Berechnung statt späterem Incident

Hypothetisches Modell: Ein Premium-Benutzer besitzt geplante Importe in zwei Umgebungen. Die verwendeten Aktionen zählen; es sind weder Process-Flows noch ein anderes besonderes Kapazitätsmodell. Ein Import hat 1 200 Datensätze mit vier gezählten Aktionen je Datensatz und weitere 200 gezählte Aktionen außerhalb dieser wiederholten vier Schritte einschließlich Trigger und Schleifensteuerung.

Das offizielle Kontingent von 40 000 ist um 5 500 überschritten, obwohl jeder Import nur 5 000 benötigt und aktuelle Übergangslimits den Lauf erlauben können. Nur die erste Umgebung würde 31 500 zeigen und das Problem verbergen. Retry und Paginierung werden hier zusätzlich gezählt, weil die ursprünglichen vier Aktionen und der feste Anteil sie ausschließen. Addieren Sie sie nicht erneut zu einem realen Gesamtverbrauch, der sie bereits enthält.

Für Cloudflows beschreibt die Dokumentation ein gleitendes 24-Stunden-Fenster. Eine Verarbeitung kurz vor Mitternacht und eine direkt danach ergeben daher nicht automatisch zwei unabhängige Tageskapazitäten. Ein Tagesexport zeigt Trends, belegt aber nicht jedes mögliche gleitende Fenster.

Fehler 429 kann weit unter dem Tageslimit auftreten

Dataverse Service Protection überwacht Anfragezahl, summierte Ausführungszeit und Parallelität. Genannte Standardwerte je Webserver sind 6 000 Anfragen in fünf Minuten, 1 200 Sekunden summierte Verarbeitung im gleichen Fenster und ein Parallelitätslimit von 52 oder höher je Umgebung. Die Werte können sich zwischen Umgebungen unterscheiden und sind keine universelle Leistungsgarantie je Mandant.

Die Ausführungszeit wird addiert. Mehrere aufwendige parallele Anfragen können daher innerhalb von fünf Minuten tatsächlicher Zeit 1 200 Sekunden Verarbeitung verbrauchen. Höhere Parallelität schafft keine kostenlose Rechenleistung. Sie kann den Engpass von der Anfragezahl zu Zeit oder Gleichzeitigkeit verschieben.

Beispiel: Derselbe Aufrufer sendet 7 000 Dataverse-Anfragen in vier Minuten an einen Webserver mit dem genannten Standardlimit. Der Tagesverbrauch kann unter 40 000 liegen, dennoch wird das Fünf-Minuten-Limit der Anfragezahl nicht eingehalten. Zeit oder Parallelität können früher begrenzen. Das erklärt den Mechanismus unter diesen Annahmen, verspricht aber nicht in jedem Mandanten denselben Fehler bei derselben Anfragenummer.

Beachten Sie bei Dataverse Retry-After und planen Sie Wiederholungen entsprechend. Reagieren Sie auf Überlastung nicht mit einer sofortigen unbegrenzten Retry-Schleife. Bei anderen Konnektoren gelten deren Dokumentation und Fehlermeldungen; nicht jedes API verwendet gleiche Regeln. Reduzieren Sie übergroße Chargen, verteilen Sie die Verarbeitung und verhindern Sie doppelte Geschäftsdaten durch wiederholte Operationen.

Der Bericht zeigt nicht die gesamte Power Platform

Die aktuelle Anleitung zu Zuteilung und Berichten führt im Admin Center über Licensing, Capacity add-ons und Download reports zu Microsoft Power Platform requests. Sie unterscheidet Licensed User, Non-licensed User und Per Flow Licensed Flows. Portalnavigation kann sich ändern; entscheidend bleibt auch der gewählte Berichtstyp.

Die Dokumentation bezeichnet diese herunterladbaren Berichte als Preview und beschränkt sie auf Power-Automate-API-Anfragen. In dieser Form enthalten sie nicht sämtliche API-Anfragen aus Power Apps, Dataverse und Copilot Studio. Fehlender Verbrauch belegt daher nicht zwingend fehlende Dienstaktivität.

Für den Licensed-User-Bericht sind zwei weitere Lesefehler dokumentiert. Das Kontingent kann nach Benutzer, Tag und Umgebung erscheinen, darf aber nicht mit der Umgebungszahl multipliziert werden. Bei Power Apps per app und passendem PAYG kann fälschlich null statt der entsprechenden 6 000 erscheinen. Eine Null in diesem Feld belegt daher nicht automatisch eine fehlende Lizenz.

Kapazität ergänzen oder Betrieb ändern?

Liegt das Problem tatsächlich im Gesamtanspruch, prüfen Sie passende höhere Benutzerrechte oder Process-Kapazität für den konkreten Flow. Die aktuelle Dokumentation nennt 250 000 PPR für Process und direktes Aufstocken auf einem lösungsbasierten Flow. Flowgruppen haben eigene Regeln für gemeinsame Nutzung und Stapelung; Details behandelt Premium, Process und Dienstkonten.

Das Requests-Add-on mit beschriebenem Zuwachs von 50 000 ist derzeit kein einfacher Zuweisungsschalter für einen gedrosselten Flow. Die Übersicht sagt ausdrücklich, dass es aktuell nicht Benutzern oder Flows zugewiesen werden kann. Bestellen Sie daher nicht nur anhand des Produktnamens, ohne die tatsächliche Kapazitätszuordnung zu prüfen.

Sind Konnektorlimits oder Service Protection die Ursache, beginnen Sie bei Rate, Parallelität, Operationstypen und kontrollierten Wiederholungen. Ein höheres Tageskontingent beseitigt die Regeln des Ziel-API nicht. Verwechseln Sie Dataverse-Anfragekapazität auch nicht mit Datenbank-, Datei- oder Protokollspeicher. Diese Messgrößen erläutert unser Dataverse-Kapazitätsartikel.

Vorgehen bei Verlangsamung oder Fehler

1. Zeitpunkt, Flow- und Run-ID, konkrete Aktion, Konnektorantwort und gegebenenfalls Retry-After sichern.
2. Anfragekontingent, Power-Automate-Betriebsgrenze, Konnektor und Dataverse Service Protection unterscheiden.
3. Flowtyp, tatsächlichen Eigentümer beziehungsweise auslösenden Benutzer und Kapazitätsmodell prüfen.
4. Relevanten Verbrauch einschließlich anderer Flows und Umgebungen desselben Benutzers addieren; dieselbe Lizenz nicht mehrfach anrechnen.
5. Gesamtverbrauch von kurzen Spitzen trennen und gleitendes Fenster berücksichtigen.
6. Gezielte Abhilfe wählen: Kapazität, weniger unnötige Aktionen, verteilte Chargen oder gesteuerte Parallelität.
7. Abgeschlossenen Geschäftsvorgang statt nur erfolgreichen Retry prüfen. Auch doppelte und unverarbeitete Elemente kontrollieren.