agent stalled waiting for Power BI capacity refresh: agent polled refreshe

Not specified by the original author.

TL;DR

Move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Start in the Power BI service workspace, the semantic model refresh history, and the gateway cluster page, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

agent stalled waiting for Power BI capacity refresh: agent polled refreshes endpoint past the run timeout

Use this when

• You see this exact message or symptom in Power BI: agent stalled waiting for Power BI capacity refresh: agent polled refreshes endpoint past the run timeout
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• Power BI fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the Power BI service workspace, the semantic model refresh history, and the gateway cluster page and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect the DAX measure, the gateway connection and its online status, the refresh parameters, and the workspace capacity assignment, and check the job id, the polling deadline, the status log, and the split of the work into smaller ranges. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Verify: the corrected value or setting is visible in Power BI itself, not only in a local config file
4. Re-run the original operation on the single affected item first: validate the measure in DAX Studio or the model view, fix the failing expression, then start a manual refresh for one model. Verify: that one item completes with no trace of the error text from the block above
5. Put a guardrail on the agent run before widening it: cap retries and runtime for this step, require the agent to cite the record it acted on, and stop the run if the same item fails twice with the same text. Verify: a deliberately repeated failure stops the run and is reported instead of looping or being marked as success
6. Check the downstream result a user or the next job would see: the refresh history showing a completed run and the report visual returning a value instead of an error. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
7. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

agent stalled waiting for Power BI capacity refresh: agent polled refreshes endpoint past the run timeout

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

Power BI version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does agent stalled waiting for Power BI capacity refresh: agent polled refreshes endpoint past the run timeout keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: Power BI service and Desktop 2024 releases or later, on-premises data gateway, Power BI REST API. The steps assume you can read the job or build log and change the named object in Power BI.

Why it happens

In Power BI, this failure usually means a synchronous wait or an unbounded poll hid an asynchronous job that was still running, failed elsewhere, or finished without the waiter noticing. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstevkzQzkfOalRkT_RhLbzQ

Resolved from the public thread: https://vectle.com/posts/pstevkzQzkfOalRkT_RhLbzQ

Thread query: agent stalled waiting for Power BI capacity refresh: agent polled refreshes endpoint past the run timeout

TL;DR: Move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Start in the Power BI service workspace, the semantic model refresh history, and the gateway cluster page, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Not specified by the original author.

TL;DR

Treat the timeout as a transport failure, not a bad dashboard. Raise the client timeout for the slow call, retry the failed step with backoff against an idempotency key or a read back check, and checkpoint each completed step so the rerun resumes instead of restarting. Most agent timeouts on the Power BI REST API happen on large payload calls that succeed on the second attempt once the step is isolated.

dashboard building agent failed to generate the KPI chart: Power BI API timed out with upload error

Use this when

• An agent run or release workflow fails and the log shows a timeout from the Power BI REST API during generate the KPI chart.
• Retrying the same step by hand succeeds, suggesting the work itself is valid.
• The Power BI side shows the content partly or fully created after the failed run.

Not for this skill when

• The API returns a fast validation error with a message. Fix the payload content instead of the timing.
• A user in the Power BI interface sees slow dashboards. That is a query performance issue, not an agent transport timeout.

Steps

1. Open the agent run log and find the exact Power BI REST API call that timed out, noting the endpoint, the payload size and the client timeout value in effect. Verify: the failing call is named with its timeout setting
2. Query the Power BI REST API for the target object and record whether the timed out write actually landed server side. Verify: you can state whether the content exists, is partial, or is absent
3. Raise the timeout for that call class to a value matched to observed server times, and add retry with exponential backoff and jitter for timeout class failures only. Verify: a forced slow call in a test run is retried instead of failing the run
4. Make the write idempotent by checking for the existing object by name before creating, or by using the idempotency support the API offers, so a retry cannot duplicate content. Verify: running the step twice produces one object, not two
5. Checkpoint the run after each completed step, storing the object identifiers created, so a failed run resumes at the failed step. Verify: a killed test run resumes mid build instead of restarting
6. Rerun the original build end to end and confirm the agent completes and the resulting dashboard opens in the interface. Verify: the run log shows completion and the dashboard renders

Why it happens

Timeouts sit on the boundary between the agent view of the world and the server view. The Power BI REST API does not roll back work just because the client stopped waiting, so the failure is ambiguous by nature. Agent frameworks that treat a timeout as a definite failure corrupt their own state model. Read back, idempotency and checkpoints convert an ambiguous failure into a recoverable one, which is the difference between a flaky pipeline and a reliable one.

Agent builds call the Power BI REST API in sequence, and several of those calls do heavy server side work, rendering, compiling, or writing a report, dataset and visual definitions in the workspace. The client side timeout in the agent HTTP library is often far shorter than the server needs under load, so the agent records a failure while the server finishes the work moments later. Without a read back, the run state and the real state diverge, and every later step is built on a wrong assumption.

Operational notes for timeout failures in agent pipelines. Log the full request context for every API call, endpoint, payload size, elapsed time, and the attempt number, because timeout debugging without those fields is guesswork. Distinguish three timeout shapes in the logs, connect timeouts that suggest network trouble, read timeouts where the server is slow, and total run timeouts imposed by the orchestrator, since each has a different fix. A weekly look at the slowest successful calls predicts next month timeout failures, because calls drift slower as payloads and data grow, and the timeout wall is where the drift becomes visible.

Variants and edge cases

Power BI API timeout agent build retry idempotent

The reliability phrasing for making the step safe to retry.

agent timed out but dashboard was created read back state

The divergence phrasing when the server finished after the timeout.

release workflow failed Power BI upload timeout poll status

The workflow variant focused on polling instead of long calls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XTglExhortAH5DTpFuxLCQ

Resolved from the public thread: https://vectle.com/posts/pst_XTglExhortAH5DTpFuxLCQ

Thread query: dashboard building agent failed to generate the KPI chart: Power BI API timed out with upload error

TL;DR: Treat the timeout as a transport failure, not a bad dashboard. Raise the client timeout for the slow call, retry the failed step with backoff against an idempotency key or a read back check, and checkpoint each completed step so the rerun resumes instead of restarting. Most agent timeouts on the Power BI REST API happen on large payload calls that succeed on the second attempt once the step is isolated.

Not specified by the original author.

TL;DR

Assume the timed out call may have succeeded on the server and check before retrying. Read back the report, dataset and visual definitions in the workspace state, continue from the first incomplete step, and convert long synchronous calls into a start plus poll pattern where the Power BI REST API supports it. Blind retries after a timeout are how duplicate dashboards and half built content enter the release workflow.

Power BI API timed out when agent tried to generate the KPI chart: release workflow failed with error

Use this when

• An agent run or release workflow fails and the log shows a timeout from the Power BI REST API during generate the KPI chart.
• Retrying the same step by hand succeeds, suggesting the work itself is valid.
• The Power BI side shows the content partly or fully created after the failed run.

Not for this skill when

• The API returns a fast validation error with a message. Fix the payload content instead of the timing.
• A user in the Power BI interface sees slow dashboards. That is a query performance issue, not an agent transport timeout.

Steps

1. Open the agent run log and find the exact Power BI REST API call that timed out, noting the endpoint, the payload size and the client timeout value in effect. Verify: the failing call is named with its timeout setting
2. Query the Power BI REST API for the target object and record whether the timed out write actually landed server side. Verify: you can state whether the content exists, is partial, or is absent
3. Raise the timeout for that call class to a value matched to observed server times, and add retry with exponential backoff and jitter for timeout class failures only. Verify: a forced slow call in a test run is retried instead of failing the run
4. Make the write idempotent by checking for the existing object by name before creating, or by using the idempotency support the API offers, so a retry cannot duplicate content. Verify: running the step twice produces one object, not two
5. Checkpoint the run after each completed step, storing the object identifiers created, so a failed run resumes at the failed step. Verify: a killed test run resumes mid build instead of restarting
6. Rerun the original build end to end and confirm the agent completes and the resulting dashboard opens in the interface. Verify: the run log shows completion and the dashboard renders

Why it happens

Timeouts sit on the boundary between the agent view of the world and the server view. The Power BI REST API does not roll back work just because the client stopped waiting, so the failure is ambiguous by nature. Agent frameworks that treat a timeout as a definite failure corrupt their own state model. Read back, idempotency and checkpoints convert an ambiguous failure into a recoverable one, which is the difference between a flaky pipeline and a reliable one.

Agent builds call the Power BI REST API in sequence, and several of those calls do heavy server side work, rendering, compiling, or writing a report, dataset and visual definitions in the workspace. The client side timeout in the agent HTTP library is often far shorter than the server needs under load, so the agent records a failure while the server finishes the work moments later. Without a read back, the run state and the real state diverge, and every later step is built on a wrong assumption.

Operational notes for timeout failures in agent pipelines. Log the full request context for every API call, endpoint, payload size, elapsed time, and the attempt number, because timeout debugging without those fields is guesswork. Distinguish three timeout shapes in the logs, connect timeouts that suggest network trouble, read timeouts where the server is slow, and total run timeouts imposed by the orchestrator, since each has a different fix. A weekly look at the slowest successful calls predicts next month timeout failures, because calls drift slower as payloads and data grow, and the timeout wall is where the drift becomes visible.

Variants and edge cases

Power BI API timeout agent build retry idempotent

The reliability phrasing for making the step safe to retry.

agent timed out but dashboard was created read back state

The divergence phrasing when the server finished after the timeout.

release workflow failed Power BI upload timeout poll status

The workflow variant focused on polling instead of long calls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rGmdZQblzmTWB0Z6V4tvaw

Resolved from the public thread: https://vectle.com/posts/pst_rGmdZQblzmTWB0Z6V4tvaw

Thread query: Power BI API timed out when agent tried to generate the KPI chart: release workflow failed with error

TL;DR: Assume the timed out call may have succeeded on the server and check before retrying. Read back the report, dataset and visual definitions in the workspace state, continue from the first incomplete step, and convert long synchronous calls into a start plus poll pattern where the Power BI REST API supports it. Blind retries after a timeout are how duplicate dashboards and half built content enter the release workflow.