What causes Understanding memory errors and recovery?

Temporary high demand on the Premium capacity causing memory contention across multiple semantic models simultaneously. A large semantic model consuming most available capacity memory, leaving insufficient headroom for concurrent operations on other models. A spike in user activity or scheduled refreshes all triggering at the same time, exhausting the capacity's available memory pool. A semantic model that persistently exceeds capacity memory limits due to unbounded data growth over time

How do I fix Understanding memory errors and recovery?

Step 1: Wait a few minutes and retry the failed operation — Premium capacity load balancing is automatic and memory errors during peak periods often resolve without manual intervention.. Step 2: Check the Power BI Premium Capacity Metrics app (or MetricSign's capacity dashboard) to identify whether memory utilization was near 100% at the time of the error and which models were consuming the most memory.. Step 3: If the error recurs frequently, stagger scheduled refresh times across semantic models to avoid simultaneous memory spikes competing for the same capacity pool.. Step 4: For persistently failing models, reduce their memory footprint by limiting imported data volumes, enabling incremental refresh, or removing unused tables and columns.. Step 5: If memory exhaustion is chronic and not tied to specific spikes, evaluate upgrading the capacity SKU or distributing large semantic models across multiple workspaces on separate capacities.

Medium severitycapacity

Power BI Refresh Error:
Understanding memory errors and recovery

What does this error mean?

A memory error occurred on a Power BI Premium capacity due to high demand, causing a semantic model operation to fail. These errors are often transient — the system typically recovers automatically as memory is freed from other models.

Common causes

1Temporary high demand on the Premium capacity causing memory contention across multiple semantic models simultaneously
2A large semantic model consuming most available capacity memory, leaving insufficient headroom for concurrent operations on other models
3A spike in user activity or scheduled refreshes all triggering at the same time, exhausting the capacity's available memory pool
4A semantic model that persistently exceeds capacity memory limits due to unbounded data growth over time

How to fix it

1Step 1: Wait a few minutes and retry the failed operation — Premium capacity load balancing is automatic and memory errors during peak periods often resolve without manual intervention.
2Step 2: Check the Power BI Premium Capacity Metrics app (or MetricSign's capacity dashboard) to identify whether memory utilization was near 100% at the time of the error and which models were consuming the most memory.
3Step 3: If the error recurs frequently, stagger scheduled refresh times across semantic models to avoid simultaneous memory spikes competing for the same capacity pool.
4Step 4: For persistently failing models, reduce their memory footprint by limiting imported data volumes, enabling incremental refresh, or removing unused tables and columns.
5Step 5: If memory exhaustion is chronic and not tied to specific spikes, evaluate upgrading the capacity SKU or distributing large semantic models across multiple workspaces on separate capacities.

Frequently asked questions

How can I tell if a memory error was truly transient versus a structural capacity problem?

A transient error typically occurs once during a known peak period and does not repeat. A structural problem shows up repeatedly, often at the same time each day (e.g., during scheduled refresh windows), or affects the same model consistently regardless of time. Use the Premium Capacity Metrics app or MetricSign to review memory utilization history alongside error timestamps.

Does Power BI automatically retry a failed refresh caused by a memory error?

Power BI does not automatically retry a dataset refresh that fails due to a memory error — the refresh will be marked as failed and you must manually trigger it or wait for the next scheduled window. For XMLA-initiated operations, retry logic must be implemented in the calling application.