The red exclamation mark on Monday morning
Someone opens the sales dashboard and the figures are from Thursday. In the Power BI service there is a red warning: refresh failed. The error mentions a data source credential, or a gateway that is offline, or a timeout. Somebody reruns it by hand, it works, and the same thing happens next week.
Over time the team learns to check the last refresh time before trusting anything. Some start asking for the data in Excel instead, which defeats the point of paying for the dashboard.
Why refreshes fail more than they should
Power BI itself is rarely the cause. The problem is the route the data takes to reach it, which was usually set up quickly when the first report was built and then extended.
| Common cause | What is really going on |
|---|---|
| Gateway offline | The gateway runs on an office PC or small server that sleeps, restarts or loses network |
| Credentials expired | A personal account was used for a source and its password or token changed |
| Timeouts | Heavy transformations run in Power Query against a live system every refresh |
| Excel or SharePoint source errors | Someone renamed, moved or opened the file during refresh |
| Schema errors | A column was renamed or removed in the source |
| Capacity limits | Large imports on a shared capacity or Pro licence |
Several of these usually combine. A report that pulls from a spreadsheet on someone's OneDrive through a gateway on a desktop PC using a personal login has many ways to fail.
What an unreliable refresh costs
- Decisions made on stale figures without anyone realising
- A person spending part of every week rerunning refreshes and chasing errors
- Trust in the dashboard draining away, and spreadsheets coming back
- Heavy refresh queries slowing down the live system staff use
The first one is the dangerous one. A failed refresh does not blank the dashboard. It shows old numbers that look current unless you check the timestamp.
How we make Power BI refresh reliably
- We review every data source, the gateway, the credentials used and the refresh history, and list what is failing and why.
- We move heavy transformation work out of Power Query into a staging database, such as Azure SQL or Postgres, loaded by scheduled pipelines. Power BI then reads prepared tables instead of rebuilding them every time.
- Spreadsheet sources that are really data entry get replaced with a proper table or a SharePoint list with controlled columns, or at minimum moved to a fixed location with protected structure.
- Credentials move from personal accounts to service accounts or service principals, so a staff member changing their password stops breaking reports.
- If a gateway is still needed, it runs on a maintained server or VM, in a cluster where appropriate, not on someone's laptop.
- We add incremental refresh for large tables where your licence supports it, so only recent data is reloaded.
- Every refresh is monitored. Failures send an alert to a named person with the reason, and the report shows its last successful refresh time clearly.
Your reports, measures and visuals stay as they are. Users usually notice nothing except that the numbers are current.
When refresh stops being a topic
The dashboard shows yesterday's data every morning. When a source genuinely has a problem, the right person knows before users do, and the report says the data is delayed rather than showing stale figures as if they were fresh.
The source systems also get relief, because Power BI is no longer running heavy queries against them several times a day.
Is this your Power BI setup?
- Scheduled refreshes fail regularly and get rerun by hand
- The gateway runs on a desktop PC or an old server
- Some sources use a staff member's personal login
- Excel files on OneDrive or SharePoint feed key reports
- Refreshes take a long time and sometimes time out