Power BI troubleshooting
If your power bi scheduled refresh failed, fix it by working from the most common cause down: an offline gateway, expired data-source credentials, a blocked firewall, or a query timeout. This power bi scheduled refresh failed fix guide walks each failure mode with the exact Power BI settings to check so you can restore your production dataset today.
Triage path
Open the semantic model, click Refresh history, and copy the exact error text. The message almost always names the cause, gateway, credentials, timeout, or data type, and tells you which fix below to jump to. Never guess before reading it.
An offline on-premises gateway or expired data-source credentials are the two most frequent culprits. Confirm the gateway is online and signed in, then re-enter credentials under the semantic model’s Gateway and cloud connections panel.
Use the steps here to resolve it now. If it is intermittent, environment-specific, or you need it gone by Friday, a senior engineer can fix it via prepaid Flex hours, most tasks done 3–5 business days after approval.
This is a senior-engineer triage path for a broken scheduled refresh: start at the Refresh history error and work down to the exact setting that fixes it. Because the Power BI service runs refresh unattended, the failures you see here rarely appear when you click Refresh in Desktop. The order below reflects what actually breaks production datasets most often, and it maps to Microsoft’s own guidance for troubleshooting refresh scenarios (opens in new tab).
A scheduled refresh fails when the service cannot reach or authenticate to your data source at run time. The leading causes are an offline on-premises gateway, expired or mismatched data-source credentials, a firewall blocking the gateway, an overloaded gateway node, and query timeouts or data-type errors in the model itself.
Start every diagnosis in the semantic model’s Refresh history, where Power BI logs the precise error for each failed run. The message text is your map: it usually names the failing connection and reason. Because the service runs refresh on a schedule with no human present, a credential or gateway problem that you would never see in Desktop surfaces only here. Work the causes in order of likelihood rather than rebuilding the model blindly, and you will resolve most failures in minutes.
| Failure mode | Where to check | Typical fix |
|---|---|---|
| Gateway offline / not signed in | On-premises gateway app; Refresh history | Restart gateway service, sign back in, run on an always-on host, add to a cluster |
| Expired / mismatched credentials | Semantic model Settings > Gateway and cloud connections | Edit credentials, re-enter password or token, match auth method and privacy level |
| Firewall / network blocked | Gateway host network; firewall rules | Allow outbound ports, fix DNS, check VPN or firewall changes |
| Gateway overloaded / unavailable | Refresh history; gateway load | Add gateway to a cluster, stagger refresh schedules |
| Query timeout | Refresh history error text | Add incremental refresh, fold transformations, reduce data volume |
| Data-type / conversion error | Reproduce refresh in Power BI Desktop | Fix column type or bad value in Power Query, republish |
Open the on-premises data gateway app on the host machine and confirm the service is running and the gateway shows online and signed in. Restart the gateway service if it shows offline, verify the account hasn’t been signed out, then re-run the refresh from the semantic model.
Gateways go offline when the host machine sleeps or reboots, when the gateway service account password changes, or when the machine loses network. For production refreshes, run the gateway on an always-on server rather than a laptop, and use a service account whose password does not rotate unexpectedly. If a single gateway is a single point of failure, add it to a gateway cluster (opens in new tab) so refreshes fail over to a second node instead of failing outright. Confirm the data source is registered on the gateway under Gateway and cloud connections.
In the Power BI service, open the semantic model Settings, expand Gateway and cloud connections (or Data source credentials), and click Edit credentials on the failing source. Re-enter the username and password or refresh the OAuth token, choose the correct authentication and privacy level, then save and re-run.
This is the fix for the classic message that a credential is invalid or a token has expired. Database password rotations, expired OAuth tokens for sources like SharePoint or Dynamics, and a privacy-level mismatch that blocks query folding all land here. Set the authentication method to match the source exactly and pick a privacy level that lets the queries combine. If your organization rotates database passwords on a schedule, that rotation is the recurring root cause, and switching to a managed identity or service principal where supported removes the manual re-entry for good.
For network errors, confirm the gateway host can reach the data source and that firewall rules allow outbound traffic on the required ports. For timeouts, narrow the query, add incremental refresh, or fold transformations to the source. For data-type errors, fix the offending column type or malformed value in Power Query, then republish.
A refresh that connects but then stalls is usually a timeout: large tables pulled in full, heavy Power Query steps that don’t fold, or an overloaded gateway competing with other refreshes. Incremental refresh is the durable fix because it only pulls changed rows. Network failures, by contrast, never reach the data, so check DNS resolution from the gateway machine and whether a firewall or VPN change blocked it. Data-type and conversion errors trace to a single bad value or a source schema change; reproduce the refresh in Desktop to surface the exact row, fix it, and republish the model. When the same timeout keeps returning, it is usually a modeling problem rather than a transient blip, and a round of data model and refresh tuning will do more than rerunning the schedule. If the report is also slow to open or filter, our guide on how to fix slow Power BI reports covers the model and DAX side.
Hand it off when the failure is intermittent, environment-specific, or blocking a report people depend on and you need it resolved this week. Our Power BI troubleshooting consultant reproduces the exact Refresh history error, isolates the cause, and applies the durable fix rather than a temporary rerun, so the same failure does not return next month.
That is what Power BI Flex Support is built for: prepaid blocks of senior-led hours that never expire. You buy a block (Starter 20h @ $125/hr = $2,500, Growth 40h @ $115/hr = $4,600, or Power 80h @ $100/hr = $8,000, the best value), email the failing model details, and we send a scope and hours estimate before any work begins. Most fixes land 3–5 business days after approval, hours are deducted only for approved work, and unused hours stay banked with no contract. If you would rather not buy ahead, you can still get it fixed with prepaid Flex hours and keep whatever you don’t use. For teams that want a standing safety net, our ongoing Power BI support and troubleshooting keeps a senior engineer on call for exactly these refresh outages, and a full refund applies if you are unhappy within the first four hours of a block.
Related reading
Send us the Refresh history error and the failing model. We scope it, you approve, and most refresh fixes land in 3–5 business days — on prepaid hours that never expire.
FAQ
Open the semantic model in the Power BI service, then click Refresh history. Each failed run logs the exact error message, which almost always names the cause, gateway, credentials, timeout, or data type. Copy that text first; it tells you which fix to apply before you change anything.
Desktop uses your interactive sign-in, while scheduled refresh runs unattended through the gateway and stored credentials. A source reachable from your machine may be blocked from the gateway host, or the saved credentials may have expired. Check the gateway status and re-enter data-source credentials in the model settings.
Recurring credential failures usually trace to scheduled database password rotations or expiring OAuth tokens. Where the source supports it, switch to a managed identity or service principal so there is no password to re-enter. Otherwise, document the rotation and update the data-source credentials in the service immediately after each change.
Yes. With Power BI Flex Support you buy a prepaid block of senior hours (Starter 20h at $125/hr), email the failing model details, and we send a scope and hours estimate before any work. Most fixes are done 3-5 business days after approval, and hours are deducted only for approved work.
Sometimes a refresh failure exposes timeouts or design issues that need restructuring, not just a credential reset. Flex hours cover that too: incremental refresh, query folding, or gateway-cluster setup. Banked hours never expire, so you can address the root cause without a project minimum or long-term contract.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.