Power Automate API timeout errors: diagnose and fix the 120-second limit

Power Automate has a documented 120-second limit for an outbound synchronous request. If an API has not returned within that window, the action can fail even though the overall flow is allowed to run for much longer.

The fix is not “increase the timeout”. For this class of request, you normally have to change the shape of the integration: request less work, page through the data, or use a genuine asynchronous job.

First confirm what actually timed out

Open the failed run, expand the action and record:

action name and duration;
status code and error code;
response headers, especially Retry-After, Location and request IDs;
request URL and method, with secrets removed; and
whether the failure happens at roughly the same duration every time.

Microsoft's current Power Automate limits list:

outbound synchronous request: 120 seconds;
inbound request: 120 seconds; and
outbound asynchronous request: configurable up to 30 days.

Some connector operations are asynchronous or webhook-based and can behave differently, so check the connector's own technical details as well.

A 504 is not automatically proof that Power Automate's two-minute limit fired. The API gateway, proxy or upstream application might have a shorter timeout. A 429 is throttling, not a timeout. A 401 or 403 is an authentication or permission failure. Fix the error you actually have.

Choose the repair that matches the API

1. Ask for less data per call

This is usually the best fix for a historical-data export or a large search.

Look for parameters such as:

pageSize, $top, limit or count;
from and to dates;
a cursor or continuation token; or
a server-side filter that excludes fields and rows you do not need.

Your goal is simple: every individual HTTP request must return within the limit.

Do not collect every page in one huge in-memory array unless the next action genuinely requires that. Process or write each page, store the continuation point, then request the next page. That makes recovery possible without starting the entire export again.

2. Use pagination when the API is actually pageable

Pagination does not make one slow API request faster. It only helps when the service can return smaller pages.

Microsoft documents that the workflow HTTP action can automatically follow nextLink or @odata.nextLink when its Pagination setting is available. If the service uses a different field such as next_cursor, build a loop that reads that value and stops when it is empty.

Before turning pagination on, verify:

the first response contains a documented next-page link or token;
a smaller page returns within 120 seconds;
the API defines a stable order; and
you know whether records can be added or changed while paging.

Pagination requests and retries also count as flow action runs, so “set the threshold to a very large number” is not a design.

3. Split a large history into restartable windows

If the API filters by date but has no cursor, process fixed windows such as one day or one month at a time.

For each window:

calculate the start and end;
request that range;
write the result to the destination;
record a successful checkpoint; and
advance only after the write succeeds.

Use a stable unique key at the destination so a retried window does not create duplicates. If one month still takes too long, reduce the window. The correct size comes from measured response times and volumes, not an arbitrary number in a blog post.

4. Use the API's asynchronous job pattern

For a long-running export, the clean contract is:

Power Automate submits the job.
The API quickly returns 202 Accepted.
The response includes a Location URL for job status, and optionally Retry-After.
The workflow polls that URL until the job succeeds or fails.
The workflow downloads the finished result.

Microsoft's workflow HTTP guidance describes this asynchronous polling pattern. It also documents Retry-After for spacing the checks.

This works only when the API supports an asynchronous contract, or when you control an intermediary that can provide one. Power Automate cannot invent a status URL for a synchronous endpoint.

5. Respond asynchronously when one flow calls another

This is a separate scenario from calling an external API.

When a parent flow or app calls a child flow, Microsoft says the child must respond within 120 seconds. In the child flow's Response action, Asynchronous response can return 202 and a Location header so the caller is not left waiting. Follow Microsoft's asynchronous response guidance rather than treating the child flow as a long synchronous function.

Remember: an acknowledgement is not the final business result. Decide where the eventual success, failure and output will be recorded.

Retries: useful for transient faults, useless for a deterministic timeout

Use a retry policy for temporary failures such as throttling or an intermittent 5xx response. Honour the service's Retry-After header where it provides one.

Do not use aggressive retries when the same request always takes longer than two minutes. That repeats an expensive operation, increases action consumption and can make the upstream service less healthy. Reduce or redesign the request first.

For production flows, use a simple Try/Catch structure with Scope actions:

Try: make the call and process the page;
Catch: capture the status, request ID, range or cursor and error body;
Finally: update the checkpoint and monitoring record appropriately.

Microsoft's Power Automate error-handling guidance recommends scopes and targeted retry policies for transient faults.

Would moving to Azure Logic Apps fix it?

Not automatically.

Microsoft currently documents an outbound HTTP limit of 120 seconds for multitenant Logic Apps and 225 seconds by default for single-tenant Logic Apps. Some managed connector settings have their own limits. Logic Apps can be the right platform for networking, deployment, monitoring or throughput reasons, but an extra 105 seconds is not a durable answer to an endpoint whose runtime keeps growing.

Use the Logic Apps limits reference for the hosting model and action you will actually deploy.

The same warning applies to Azure Functions: moving slow code into a function does not help if Power Automate still calls it synchronously and waits beyond 120 seconds. Give the function an asynchronous job contract, or return a small response quickly and continue the work safely elsewhere.

Things that sound like fixes but are not

Proposed fix	Why it fails
Increase the action timeout to 10 minutes	The documented outbound synchronous limit is still 120 seconds.
Turn on pagination	It helps only if the API returns smaller pages with a supported next-page mechanism.
Add more retries	A deterministic two-minute request will simply fail repeatedly.
Move the same call to Logic Apps	The timeout changes by hosting model; it does not become unlimited.
Put the call in an Azure Function	The caller still times out unless the contract becomes asynchronous or the function responds quickly.
Append all pages to one array	Large state is slow, hard to resume and easy to duplicate after a retry.

A practical decision path

Does one smaller page finish within 120 seconds? Use pagination or smaller date ranges.
Does the API return a continuation token? Follow it and checkpoint each successful page.
Does the API return 202 plus a status URL? Use asynchronous polling and respect Retry-After.
Is this one flow calling another? Use the child-flow asynchronous response pattern.
Is the endpoint synchronous-only and still too slow? Change the API or add a durable asynchronous intermediary.
Can none of those be changed? The integration is not reliable enough for Power Automate as currently designed.

If your separate problem is a flow that must remain active for weeks, see how to design around Power Automate's 30-day duration limits. That is related, but it is not the same limit as a single outbound HTTP request.

Official sources

Need a second pair of eyes on the pattern before you build it? Join the Power Automate Builders Space.