Executive Summary
Who This Is For
This is for Excel-strong business analysts, reporting leads, finance and operations analysts, and accidental BI owners who maintain Power BI reports or semantic models but do not administer the tenant or gateway.
Use it when the report worked before, the scheduled refresh failed, the error message is not specific enough, and a stakeholder is waiting for the latest numbers.
The Short Answer
Do not start by rebuilding the report. Start by making the failed refresh inspectable.
Your first move is to capture five facts:
- The failed refresh history row, including status, start time, duration, and exact error text.
- Whether the refresh schedule is still enabled.
- Whether a manual service refresh and a Power BI Desktop refresh behave differently.
- Which gateway or cloud connection and credentials the semantic model is using.
- Which source file, folder, database, or query changed since the last successful refresh.
Then choose the next owner based on the strongest evidence, not the loudest guess.
What Matters
Refresh history comes first
Open the semantic model in the workspace and check Refresh > Refresh history. Capture the failed run before clicking around. You want the status, timing, duration, error text, and whether the service made repeated attempts.
If the refresh history is missing from the handover, the next person has to repeat the same digging.
Settings tell you where the failure may sit
In the semantic model settings, check three areas separately:
| Settings area | What it helps you decide | What it does not prove |
|---|---|---|
| Gateway and cloud connections | Whether Power BI can see the expected gateway or connection and whether it appears online/available | That the gateway machine can reach every source successfully |
| Data source credentials | Whether credentials are missing, expired, changed, or owned by the wrong person | That the underlying source data is healthy |
| Schedule refresh | Whether the schedule, frequency, time slot, and notifications are configured | That the refresh will complete within capacity, timeout, or source limits |
When these are mixed together, every failure sounds like a gateway issue. Keep them separate.
Desktop success narrows the problem, but does not close it
If the report refreshes in Power BI Desktop but fails in the service, that is useful. It often points away from basic query logic and toward service-side conditions such as credentials, gateway mapping, source access from the gateway machine, supported source patterns, OAuth/tenant constraints, capacity, timeout, or schedule behavior.
It does not prove the semantic model is safe. Desktop uses your local context. The service uses the published semantic model, stored settings, and the service or gateway path.
Gateway failures need a different handover
For gateway-connected sources, do not only write "gateway error." Record:
- Gateway or cloud connection name shown in settings.
- Whether it appears online, running, or unavailable.
- Whether the source exists as a gateway data source.
- Whether the server, database, file path, or source names match the model exactly.
- Who owns the gateway/data source check.
- Whether Power BI Desktop can refresh from the gateway machine, if a gateway owner can test it.
That last check usually belongs to a gateway or data owner, not the report owner.
Source files and SharePoint/OneDrive add another layer
If the model depends on Excel, CSV, OneDrive, or SharePoint files, separate two questions:
- Did Power BI synchronize the PBIX, Excel workbook, or CSV file?
- Did the semantic model refresh the actual source data used by the report?
Those are not always the same thing. If a file moved, a folder path changed, a column was renamed, or a source file was replaced, the refresh error may look like a service problem while the real issue is source drift.
Timeouts and capacity issues are not ownership failures
Some failures happen because the refresh takes too long, the semantic model is too large, the source is slow, the capacity is busy, or too many refreshes overlap. In those cases, updating credentials will not help.
Capture duration, last successful duration, model size clues, schedule time, and whether other reports refresh at the same time. That gives a BI owner or capacity admin something specific to inspect.
Decision Guide
| If you see this clue | Start with this bucket | First check | Likely next owner |
|---|---|---|---|
| The schedule is disabled after repeated failures | Schedule disabled | Resolve the underlying error, then re-enable the schedule | Report owner, then workspace/admin if blocked |
| Credentials error, forbidden access, or recent password/account change | Credentials | Data source credentials in semantic model settings | Semantic model owner or credential owner |
| Gateway offline, unavailable, or no gateway selected | Gateway availability | Gateway and cloud connections in settings | Gateway admin or data owner |
| Gateway exists but source is not mapped | Gateway source mapping | Exact server/database/path names and gateway data source users | Gateway admin |
| Desktop refresh works but service refresh fails | Service path mismatch | Credentials, gateway mapping, OAuth/tenant, supported source pattern, file path | Report owner plus gateway/data owner |
| SharePoint/OneDrive file was moved or replaced | Source file drift | File link, folder path, OneDrive tab, source connection | Report owner or file owner |
| A column/table was renamed or removed | Power Query/schema change | Desktop refresh, Power Query steps, republish need | Report owner or report builder |
| Refresh runs for a long time then fails | Timeout/capacity/model size | Duration, schedule time, model size, capacity activity | BI owner or capacity/admin owner |
| Error says source is unsupported for refresh | Unsupported source pattern | Identify the source in Desktop and compare support | Report builder |
| Nobody knows who owns the next check | Handover gap | Assign one owner, one next action, one retest time | Team lead/report owner |
Practical Options
Option 1: Quick restore
Use this when the failure is obvious: expired credentials, disabled schedule, gateway offline, or source file moved.
Fix the known issue, run Refresh now, record the retest result, and keep the failed refresh evidence. Do not close the incident just because you changed a setting. Close it after a successful retest.
Option 2: Structured triage handover
Use this when the error is vague or several components could be responsible.
Create a one-page handover with:
- Workspace, report, and semantic model name.
- Last successful refresh and failed refresh details.
- Exact error text.
- Screenshot or link to refresh history.
- Gateway/cloud connection name.
- Credential owner.
- Source files/systems involved.
- Desktop refresh result.
- Service manual refresh result.
- Likely bucket and uncertainty note.
- Assigned next owner.
- Retest plan.
This is the right move for most recurring failures because it prevents the same investigation from restarting each time.
Option 3: Rebuild or redesign
Use this only when the failure repeats because the reporting process itself is fragile: local files, changing folder structures, undocumented Power Query steps, oversized semantic models, or unclear ownership.
A rebuild is justified when triage shows the same source of failure several times. It is not justified just because the first error message was vague.
Recommended Move
For a failed scheduled refresh, make a triage handover before asking for a fix.
The handover should answer four questions:
- What exactly failed?
- What has already been checked?
- What remains uncertain?
- Who owns the next retest?
If you cannot answer those four questions, the next person is not receiving a fix request. They are receiving a mystery.
Checklist
Before you escalate, capture:
- Workspace name.
- Report name.
- Semantic model name.
- Last successful refresh time.
- Failed refresh time.
- Refresh status and duration.
- Exact error text.
- Screenshot or link to refresh history.
- Whether schedule refresh is still enabled.
- Whether refresh failure notifications are configured.
- Gateway/cloud connection shown in settings.
- Data source credentials status.
- Credential owner.
- Source file, folder, database, or system names.
- Whether a source file moved, changed name, or changed columns.
- Power BI Desktop refresh result.
- Power BI service manual refresh result.
- Whether OneDrive/SharePoint synchronization is involved.
- Whether the issue has happened before.
- Likely failure bucket.
- One uncertainty note.
- One assigned next owner.
- One retest date/time.
Evidence Notes
Use Microsoft documentation to trust what Power BI settings and troubleshooting surfaces are meant to show. Do not use it as proof that your specific tenant, gateway, credentials, source files, or capacity are healthy.
- Microsoft docs support checking refresh history, semantic model settings, gateway/cloud connections, data source credentials, and schedule refresh as separate surfaces. The operational implication is that your handover should keep those checks separate too.
- Microsoft docs state that schedules can be disabled or paused after repeated failures or inactivity. The operational implication is that "the report did not refresh" may mean the schedule stopped trying, not only that the latest run failed.
- Microsoft gateway docs support asking a gateway/data owner to test source access from the gateway machine and inspect gateway logs. The operational implication is that a report owner should not pretend to have proved gateway health from their own laptop.
- Microsoft docs support timeout, OAuth, unsupported-source, and schema/source-change failure categories. The operational implication is that updating credentials is only one possible fix, not the default fix.
- Practitioner reports are useful evidence that vague scheduled refresh and gateway errors happen in real work. They do not prove which cause applies to your model. Use them as a warning to capture better evidence before escalating.