Full Diagnostic Tree & Step-by-Step Overview
What specific error code or symptom is observed in your failed Power Automate flow run history?
- Action fails after exactly 100 seconds with status code '504 Gateway Timeout' or 'ActionTimeout'.
- Action fails via On-Premises Data Gateway with '502 Bad Gateway' or network transport disconnect.
- Flow fails with '429 Too Many Requests' or connector API throttling limits exceeded.
- HTTP / Webhook trigger or action times out waiting for an asynchronous callback or long-running task.
What is the specific connector type or execution scenario triggering the 100-second 504 Gateway Timeout?
- Custom Connector or standard HTTP action making a synchronous call to a slow backend REST endpoint.
- SQL Server action (e.g., Execute Query / Stored Procedure) running longer than 110 seconds.
- SharePoint Online / OneDrive connector timing out during large file uploads or heavy document operations.
- Excel Online (Business) connector timing out when processing large tables or running scripts.
Synchronous HTTP 100-Second Hard Limit Threshold Exceeded
Solution:
Root Cause: Synchronous Execution Boundary Breach in Azure Logic Apps Architecture
Power Automate built-in HTTP actions and custom connectors enforce a hard-coded 100-second synchronous execution limit. If the receiving REST API endpoint takes longer than 100 seconds to generate and complete an HTTP response payload, the underlying API Management proxy drops the socket connection and throws a 504 Gateway Timeout (ActionTimeout) exception.
# Diagnostic Verification:
1. Open the Power Automate Maker Portal (make.powerautomate.com).
2. Navigate to your flow's Run history and click on the failed execution run.
3. Expand the failing HTTP or Custom Connector action step.
4. Review the OUTPUTS body: Confirm statusCode: 504 and message stating The target server failed to respond within the expected time frame or ActionTimeout after approximately 1 minute and 40 seconds.
# Step-by-Step Fix:
1. Re-architect the Endpoint to Use the Asynchronous Pattern (202 Accepted):
Reconfigure the target backend REST API to return an HTTP 202 Accepted status code immediately upon request receipt, accompanied by a Location header pointing to a polling endpoint.2. Enable Asynchronous Pattern in Flow Action:
In the Power Automate flow designer, click the three dots (...) on the upper right corner of the HTTP action step card.Select Settings.Toggle Asynchronous Pattern to On.Click Done and save the flow.3. Configure ISO 8601 Custom Timeout Duration:
Under the action's Settings menu, scroll to Timeout.Enter a custom duration string using ISO 8601 syntax (e.g., PT10M for 10 minutes or P1D for 1 day) to allow polling to continue until completion.# Prevention & Long-Term Monitoring:
Implement asynchronous processing patterns across all enterprise REST endpoints designed to process tasks taking longer than 30 seconds.
SQL Server Stored Procedure or Query Processing Latency
Solution:
Root Cause: Unindexed Database Operations and Transaction Lock Escalation
When executing SQL Server connector actions (e.g., *Execute a SQL query* or *Execute stored procedure*), long-running queries caused by missing database indexes, blocking table locks, or massive result set serialization exceed the default SQL Command Timeout limit (typically 110 seconds).
# Diagnostic Verification:
1. Open SQL Server Management Studio (SSMS) or Azure Data Studio.
2. Execute the failing query or stored procedure using SQL Server Profiler or Extended Events.
3. Query active dynamic management views (DMVs) to inspect lock escalation and execution duration:
sql
SELECT r.session_id, r.status, r.command, r.cpu_time, r.total_elapsed_time, t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.total_elapsed_time > 30000;
# Step-by-Step Fix:
1. Optimize Query Execution Plan and Indexing:
Add missing non-clustered indexes on columns referenced in JOIN, WHERE, and ORDER BY clauses within your query or stored procedure.2. Implement Query Pagination and Row Filtering:
Avoid returning unrestricted SELECT * queries. Limit the output dataset by specifying top constraints or using OFFSET-FETCH pagination.3. Offload Long-Running SQL Processing to Azure Automation or SQL Agent:
Modify the flow to invoke an asynchronous Azure Automation PowerShell job or Azure Function that executes the heavy SQL operation out-of-band.Use a secondary flow step with a polling loop to check a task status table once processing finishes.# Prevention & Long-Term Monitoring:
Set up maintenance plans to re-index and update statistics regularly on databases supporting Power Automate integrations.
SharePoint Online / OneDrive Large File Serialization Timeout
Solution:
Root Cause: Large Payload Chunking Failure and Single-Request Buffer Saturation
Attempting to retrieve or transfer large files (e.g., files greater than 100 MB) through standard SharePoint Online or OneDrive for Business actions without chunking enabled forces Power Automate to buffer the entire file payload into a single HTTP stream, causing socket exhaustion and connector timeouts.
# Diagnostic Verification:
The flow run history indicates the failure occurred during a *Get file content* or *Create file* step targeting a large binary or video file.Error details state: The response payload is too large or the server timed out while streaming content.# Step-by-Step Fix:
1. Enable Allow Chunking in Connector Settings:
In the Power Automate designer, click the three dots (...) on the file action card > Settings.Toggle Allow Chunking to On.Set Chunk Size (e.g., 8MB or 16MB).2. Use Graph API Session Upload for Files Exceeding 100 MB:
Replace native connector steps with an HTTP with Microsoft Entra ID (or HTTP) action calling the Microsoft Graph API createUploadSession endpoint: http
POST [https://graph.microsoft.com/v1.0/shares/](https://graph.microsoft.com/v1.0/shares/){share-id}/driveItem/createUploadSession
3. Stream Content Directly Using SAS Tokens:
For cross-system transfers, generate a Shared Access Signature (SAS) URL and transfer content directly without passing binary streams through the Power Automate engine.# Prevention & Long-Term Monitoring:
Enforce file size validation checks early in the flow prior to executing file transfer steps.
Excel Online (Business) Large Table Calculation & Lock Timeout
Solution:
Root Cause: File Lock Contention and Uncached Calculation Engine Overhead
The Excel Online (Business) connector interacts with workbook files via Graph API sessions. If a target Excel file is concurrently open by active users, contains complex array formulas, or contains thousands of unindexed table rows, Graph API session locks fail to release, resulting in 504 Gateway Timeout or 502 Bad Gateway errors.
# Diagnostic Verification:
Flow output reveals error code OfficeOpenXMLExecutionTimeout or GraphAPIOperationTimeout during actions such as *List rows present in a table* or *Run script*.# Step-by-Step Fix:
1. Convert Raw Excel Workbooks to Dataverse or SharePoint Lists:
Migrate heavy tabular datasets out of Excel Online into Microsoft Dataverse or SharePoint Lists, which natively handle high-throughput indexed queries.2. Optimize Excel Office Scripts:
If using the *Run script* action, ensure Office Scripts avoid console.log statements inside loops and apply updates in bulk batches using range.setValues().3. Isolate Dedicated Integration Workbooks:
Do not run Power Automate flows against Excel files currently opened or edited by human users in Excel for the Web.# Prevention & Long-Term Monitoring:
Limit Excel Online tables used in Power Automate integrations to under 5,000 rows.
What specific On-Premises Data Gateway error or network behavior is reported?
- Gateway error reports '502 Bad Gateway' or 'The gateway did not receive a timely response from the upstream server'.
- Gateway host server CPU or Memory resource exhaustion causes request queuing and dropouts.
- Outbound firewall or proxy inspection terminates long-lived Azure Relay Service WebSocket connections.
- The On-Premises Data Gateway service is outdated or running in single-instance mode without high availability.
On-Premises Data Gateway Upstream Timeout / Connection Drop
Solution:
Root Cause: Gateway Processing Timeout Between Azure Service Bus Relay and On-Premises Resource
When Power Automate connects to on-premises resources (such as local SQL Server, SAP, or file shares), requests route through Azure Relay to the On-Premises Data Gateway service (
Microsoft.PowerBI.EnterpriseGateway.exe). If the local on-premises resource takes longer than 50 seconds to return data, the gateway service terminates the socket and returns a
502 Bad Gateway response to cloud services.
# Diagnostic Verification:
1. Log into the server hosting the On-Premises Data Gateway.
2. Open Event Viewer and navigate to
Applications and Services Logs >
On-Premises Data Gateway Service.
3. Search for error events containing
GatewayOperationTimeoutException or
System.TimeoutException.
4. Review the Gateway local log files located at:
C:\Users\PBIEgwService\AppData\Local\Microsoft\on-premises data gateway\Gateway*.log
# Step-by-Step Fix:
1. Increase Gateway Timeout Configuration Settings:
Open File Explorer on the gateway host machine and navigate to: C:\Program Files\On-premises data gateway\Microsoft.PowerBI.EnterpriseGateway.exe.config
Edit the file in a text editor as Administrator.Locate and update the configuration key value (or add it if missing): xml
<add key="SqlTimeout" value="300" />
Save the file.2. Restart the Gateway Service:
Open services.msc and restart the On-premises data gateway service.3. Refer to official
Microsoft On-Premises Data Gateway Architecture Documentation for network configuration details.
# Prevention & Long-Term Monitoring:
Keep the On-Premises Data Gateway host server on the same high-speed local network subnet as the target database/resource.
On-Premises Gateway Host Resource Exhaustion & Request Throttling
Solution:
Root Cause: CPU/Memory Starvation and Thread Pool Contention on Gateway Host
If an On-Premises Data Gateway server processes multiple concurrent Power Automate flows, Power BI refreshes, and Apps requests, the
Microsoft.PowerBI.EnterpriseGateway.exe process starves available CPU cores and system RAM. Pending requests fill the gateway execution queue until timeouts occur.
# Diagnostic Verification:
1. Open Performance Monitor (
perfmon.msc) on the gateway machine.
2. Add counters for
% Processor Time and
Available MBytes for the
Microsoft.PowerBI.EnterpriseGateway process.
3. Check if CPU usage hits 100% or available RAM drops below 500 MB during flow failure windows.
# Step-by-Step Fix:
1. Enable Gateway System Resource Logging:
Open the On-Premises Data Gateway Configurator app.Select Diagnostics > Enable Additional logging.Review performance logs in C:\Users\PBIEgwService\AppData\Local\Microsoft\on-premises data gateway\PerformanceReport*.csv.2. Restrict CPU Spikes by Enforcing Gateway Throttling:
Open Microsoft.PowerBI.EnterpriseGateway.exe.config and set concurrency limits: xml
<add key="MashupPipelineTraceEnabled" value="False" />
<add key="ResourceGoverningCpuThreshold" value="80" />
3. Scale Out Infrastructure:
Upgrade the host server to a minimum of 8 vCPUs and 16 GB RAM.# Prevention & Long-Term Monitoring:
Separate heavy Power BI scheduled refresh workloads onto a dedicated gateway cluster separate from real-time Power Automate flows.
Firewall / Proxy Termination of Azure Relay WebSockets
Solution:
Root Cause: Outbound Packet Inspection Terminating Long-Lived Azure Service Bus Relay Connections
The On-Premises Data Gateway communicates with Azure Relay using outbound TCP ports (443, 5671, 5672, 9350–9354). Deep Packet Inspection (DPI) firewalls, SSL-inspecting proxies, or corporate intrusion prevention systems (IPS) periodically reset long-lived outbound WebSocket channels, forcing gateway reconnect drops.
# Diagnostic Verification:
1. Open PowerShell on the gateway server.
2. Test network connectivity to Azure Relay endpoints:
powershell
Test-NetConnection -ComputerName "*.servicebus.windows.net" -Port 443
3. Run the gateway network ports test tool:
Open On-premises data gateway configurator > Diagnostics > Click Network ports test.# Step-by-Step Fix:
1. Configure Gateway to Force HTTPS Communication Mode:
Open the On-Premises Data Gateway Configurator.Navigate to Network tab.Switch Network mode from Autodetect / Direct to HTTPS.Click Apply.2. Add Domain Whitelist Exceptions to Corporate Firewall:
Whitelist all outbound Azure Service Bus IP ranges and domain endpoints (*.servicebus.windows.net, *.frontend.clouddatahub.net).Bypass SSL inspection / TLS interception on gateway outbound traffic.# Prevention & Long-Term Monitoring:
Re-evaluate firewall rules after corporate network security updates to ensure Azure Relay endpoints remain unblocked.
Single Point of Failure / Gateway Cluster Misconfiguration
Solution:
Root Cause: High-Availability Failover Misconfiguration and Outdated Client Version
Running an outdated On-Premises Data Gateway release (older than 6 months) or relying on a single gateway instance without high-availability clustering results in unhandled connector failures when the host machine undergoes automated OS patching or reboot cycles.
# Diagnostic Verification:
1. Open Power Platform Admin Center (admin.powerplatform.microsoft.com).
2. Navigate to Data (on-premises) > Data Gateways.
3. Check the status and version number of your registered gateway instances.
# Step-by-Step Fix:
1. Update Gateway to Latest Monthly Build:
Download the latest gateway installer from the Power Automate portal and run the in-place upgrade on host servers.2. Configure High Availability Gateway Cluster:
Install a second gateway instance on a separate physical/virtual server.During setup, select Add to an existing gateway cluster.Select your primary gateway cluster name.3. Enable Load Balancing Across Cluster Nodes:
In the Power Platform Admin Center, select the gateway cluster > Settings.Enable Distribute requests across all active gateways in this cluster.# Prevention & Long-Term Monitoring:
Establish a monthly maintenance schedule to keep gateway software within 3 versions of the current release.
What type of API throttling or rate-limiting pattern is affecting the connector?
- Connector action returns '429 Too Many Requests' with a Retry-After header value.
- Flow execution is throttled due to Power Platform Request (PPR) daily license quota limits.
- Apply to each loop executing concurrent API requests saturates third-party service rate limits.
- Dataverse / Dynamics 365 Service Protection API Limits trigger 429 concurrency errors.
API Rate-Limiting (HTTP 429) & Retry-After Policy Management
Solution:
Root Cause: External API Rate-Limit Breach and Improper Exponential Backoff
When a connector action sends requests faster than allowed by the target service's API rate governor (e.g., SharePoint, Graph, or Custom API), the service responds with
HTTP 429 Too Many Requests. If the flow's retry policy is disabled or unconfigured, the flow terminates as failed instead of waiting out the requested delay.
# Diagnostic Verification:
1. Open the failed flow run step details.
2. Inspect
OUTPUTS headers for:
HTTP/1.1 429 Too Many Requests
Retry-After: 30 (indicates recommended backoff duration in seconds).
# Step-by-Step Fix:
1. Configure Action Retry Policy:
Click the three dots (...) on the failing connector action card > Settings.Under Retry Policy, select Exponential Interval.Set Count to 8 (maximum attempts).Set Minimum Interval to PT10S and Maximum Interval to PT1H.2. Add Explicit Delay Action Using Retry-After Header:
Insert a Delay action before or after the API call.Use an expression to dynamically read the Retry-After header if present: json
int(first(action()?.outputs?.headers?['Retry-After']))
# Prevention & Long-Term Monitoring:
Batch API operations wherever possible instead of issuing repetitive single-item HTTP calls.
Power Platform Request (PPR) License Quotas Exceeded
Solution:
Root Cause: User/Flow Entitlement Throttling Limits Reached
Power Automate enforces daily Power Platform Request (PPR) limits per user and per flow license tier (e.g., 40,000 requests/24 hours for standard user licenses). When a high-frequency loop or infinite trigger loop exceeds this 24-hour quota, the Power Platform engine delays or fails subsequent flow step executions.
# Diagnostic Verification:
1. Open the Power Platform Admin Center (admin.powerplatform.microsoft.com).
2. Navigate to Resources > Capacity > Analytics tab > Power Automate.
3. Review the Actions and Throttled flows reports for your environment.
# Step-by-Step Fix:
1. Assign a Process License (Formerly Flow per-flow license):
Assign a dedicated Power Automate Process License to the specific flow in the Maker Portal, raising daily capacity to 250,000 requests/day.2. Optimize Flow Logic to Reduce Action Counts:
Replace multi-step *Apply to each* loops containing nested conditions with native Filter array and Select data manipulation operations.3. Change Flow Service Principal Owner:
Re-assign flow ownership to a dedicated Non-Interactive Service Principal account with higher API entitlements.# Prevention & Long-Term Monitoring:
Configure tenant capacity alerts to notify administrators when user licenses exceed 80% of daily PPR allocation.
Concurrency Limit Saturation in Apply to Each Loops
Solution:
Root Cause: High-Parallelism Thread Saturation on Target Connectors
By default, Power Automate *Apply to each* loops execute sequentially. If a developer enables Concurrency Control and sets the degree of parallelism to its maximum value (50 concurrent threads), the flow floods the target connector with simultaneous API calls, triggering 429 rate-limit errors and thread timeouts.
# Diagnostic Verification:
Flow fails inside an *Apply to each* loop processing hundreds of items.Multiple loop iterations fail simultaneously with 504 Gateway Timeout or 429 Rate Limit status codes.# Step-by-Step Fix:
1. Reduce Concurrency Degree of Parallelism:
Click the three dots (...) on the Apply to each loop card > Settings.If Concurrency Control is ON, reduce the Degree of Parallelism slider from 50 down to 5 or 10.2. Revert to Sequential Execution:
For sensitive target connectors, turn Concurrency Control OFF to process items sequentially.3. Batch Inputs Using Chunking Expressions:
Split large arrays into smaller sub-arrays using XPath/JSON expressions before processing through loops.# Prevention & Long-Term Monitoring:
Test concurrent loops against non-production endpoints to determine the maximum sustainable thread limit.
Dataverse / Dynamics 365 Service Protection API Limits Triggered
Solution:
Root Cause: Dataverse Service Protection Throttling (3-Minute Window Limits)
Microsoft Dataverse enforces Service Protection API limits based on three metrics: Number of requests (6,000 per 5-minute window), Execution time (20 minutes of execution per 5-minute window), and Concurrent requests (52 concurrent requests). Exceeding these triggers OrganizationRequestHostHttpException (429).
# Diagnostic Verification:
1. Review flow run outputs for Dataverse actions.
2. Look for error message: Number of requests exceeded the limit of 6000 within 300 seconds or Execution time limit exceeded.
# Step-by-Step Fix:
1. Implement Dataverse Batching via Web API or Executemultiple:
Replace individual *Add a new row* actions inside loops with bulk Dataverse actions or custom HTTP calls using $batch requests.2. Use Dataverse Change Tracking for Triggers:
Replace polling triggers with native *When a row is added, modified or deleted* (Dataverse) triggers using precise filter expressions to eliminate redundant runs.3. Distribute Workloads Across Users:
Distribute high-volume batch operations across multiple application user connections to spread rate limits.# Prevention & Long-Term Monitoring:
Utilize Dataverse change notifications and Webhook integrations instead of high-frequency scheduled polling flows.
What specific trigger or webhook execution mechanism is timing out?
- HTTP Webhook trigger or action times out waiting for the external service callback.
- Child Flow invocation times out when called from a Parent Flow using Run a Child Flow action.
- Approval action times out or fails after waiting days for a user response.
- Power Apps button trigger fails with 'Response action timed out' on the client device.
HTTP Webhook Callback Failure & Listener Subscription Timeout
Solution:
Root Cause: Unregistered Callback URL or Missing Asynchronous Handshake
The HTTP Webhook action subscribes to an external service by passing a generated callbackUrl. If the external service fails to invoke the callbackUrl with a completion payload, or if the initial subscription POST request times out during handshake registration, the flow hangs and eventually fails.
# Diagnostic Verification:
1. Inspect the HTTP Webhook step in the flow run history.
2. Check the Subscribe - Outputs to verify the callbackUrl was generated.
3. Confirm whether the action failed at the subscription phase (0 seconds) or after the timeout limit reached.
# Step-by-Step Fix:
1. Validate External Service Callback Capability:
Ensure the external service can route outbound HTTPS requests to Power Automate endpoints (*.azure-apim.net).2. Configure Unsubscribe Action Pattern:
Populate the Unsubscribe - URI field in the Webhook step so that Power Automate cleanly unregisters callback endpoints if the flow is cancelled or times out.3. Implement Fallback Polling Loop:
If the external service does not guarantee reliable Webhook delivery, replace the Webhook action with an HTTP POST action followed by a Do until polling loop.# Prevention & Long-Term Monitoring:
Test Webhook callback endpoints independently using tools like Postman prior to embedding in production flows.
Parent / Child Flow Invocation Timeout
Solution:
Root Cause: Child Flow Synchronous Response Timeout (Beyond 100 Seconds)
When a Parent Flow calls a Child Flow using the *Run a Child Flow* action, the Parent Flow waits synchronously for the Child Flow to complete and return data via the *Respond to a PowerApp or flow* action. If the Child Flow processing time exceeds 100 seconds, the parent action throws a 504 timeout error.
# Diagnostic Verification:
1. Open the Child Flow's run history.
2. Check if the Child Flow is still running or completed successfully *after* the Parent Flow already failed with a timeout error.
# Step-by-Step Fix:
1. Decouple Parent and Child Flows Using Queues:
Instead of calling the Child Flow directly, have the Parent Flow send a message to an Azure Service Bus Queue or Storage Queue.Trigger the Child Flow using the *When a message is received in a queue* trigger.2. Return Early Response in Child Flow:
Move the *Respond to a PowerApp or flow* action near the top of the Child Flow (immediately after input validation) so it returns HTTP 200 to the Parent Flow before initiating heavy operations.3. Utilize Run Asynchronously Pattern:
Allow the Child Flow to process remaining steps independently out-of-band.# Prevention & Long-Term Monitoring:
Keep synchronous Child Flows lightweight, ensuring execution duration remains strictly under 15 seconds.
Approval Action Execution Timeout (30-Day Hard Boundary)
Solution:
Root Cause: Power Automate 30-Day Flow Run Lifetime Expiration
Power Automate enforces an absolute 30-day maximum lifetime limit for any single flow execution run. If a *Start and wait for an approval* action remains pending for 30 days without user interaction, the entire flow run expires automatically with status TimedOut.
# Diagnostic Verification:
1. Navigate to Run history in the Power Automate portal.
2. Locate the failed approval flow run.
3. Observe that the duration reads exactly 30.00:00:00 and status indicates TimedOut.
# Step-by-Step Fix:
1. Set Custom Action Timeout Under 30 Days:
In the flow designer, click the three dots (...) on the Approval action card > Settings.Set Timeout to P29D (29 days) or P7D (7 days).2. Add Parallel Time-Out Handling Branch:
Add a parallel branch after the Approval action.Click the three dots on the new action > Configure run after.Check has timed out (and uncheck *is successful*).Add logic in this branch to send reminder emails, escalate to managers, or update tracking lists.3. Build Auto-Renewal Approval Pattern:
For long-running business processes, store approval states in a Dataverse table and use a daily scheduled flow to check and re-issue approvals as necessary.# Prevention & Long-Term Monitoring:
Implement automated notification reminders every 3 days to approvers to resolve pending tasks before expiration.
Power Apps Synchronous Response Timeout (App Freezing)
Solution:
Root Cause: Client Canvas App Synchronous Wait State Exhaustion
When a Canvas Power App triggers a Power Automate flow using the FlowName.Run() formula and expects return parameters via the *Respond to a PowerApp or flow* action, the Power Apps client interface blocks user interaction. If the flow processing exceeds 30–60 seconds, the app client times out and drops the return payload.
# Diagnostic Verification:
The Power App displays a network error or loading spinner indefinitely when invoking FlowName.Run(), followed by Set(varResult, FlowName.Run()) returning blank variables.# Step-by-Step Fix:
1. Offload Heavy Processing to Asynchronous Background Flows:
Remove the *Respond to a PowerApp or flow* action from the primary flow.Have the Power App write a record to a Dataverse/SharePoint table, and use an automated flow triggered on record creation to perform background tasks.2. Return Immediate Success Response to App:
Place the *Respond to a PowerApp or flow* action at the very beginning of the flow execution path, returning a 200 OK status immediately while secondary actions run in parallel.3. Implement In-App Polling Status Indicator:
In the Canvas App, use a Timer Control to periodically check a status field in the database until background processing completes.# Prevention & Long-Term Monitoring:
Never perform heavy data transformations or third-party web calls synchronously inside flows directly invoked by Power Apps UI controls.