Troubleshooting Tile Errors in Power BI Dashboards - What the Red Cross Actually Means

There is a particular flavour of Monday morning email that every Power BI person recognises. It arrives at 8:41am, it is from someone senior, and it says some version of "the dashboard is broken". You open it, and sure enough, one or more tiles on the executive dashboard are showing a little error icon instead of the number that is meant to be there. The board meeting is at nine. No pressure.

Tile errors are one of the most common support issues we get called about, and the frustrating thing is that the error itself usually tells you almost nothing useful at first glance. You get a red cross or a "couldn't retrieve the data for this tile" message and not much else. But there is a logic to what causes them, and once you understand the handful of usual suspects you can diagnose most of these in a couple of minutes instead of an hour of panic. The Microsoft documentation on troubleshooting tile errors covers the mechanics. This post is about what actually goes wrong in practice, in the order you should check.

First, understand what a tile actually is

The thing people miss is that a dashboard tile is not the same as a report visual, even though they look identical. A report visual queries the semantic model live every time you open the report. A dashboard tile is a cached snapshot. When you pin a visual to a dashboard, Power BI stores a rendered version of it and refreshes that cache on a schedule, tied to the underlying semantic model's refresh.

This distinction is the key to almost everything about tile errors. When a tile shows an error, it is telling you that at the last refresh attempt, Power BI could not rebuild that cached snapshot. So the fault is almost never in the tile. It is upstream, in the refresh of the model the tile depends on. Chasing the tile itself is chasing the symptom. You want to look at what feeds it.

I labour this point because it changes how you triage. The first question is never "what is wrong with this tile". It is "did the semantic model behind this tile refresh successfully". Nine times out of ten, if you go and look at the model's refresh history, you will find a failed refresh sitting right there, and the tile error is just the visible downstream consequence.

The usual suspects, in order

Here is roughly the order we work through when a client reports broken tiles, because it maps to how common each cause is.

The scheduled refresh failed. This is the number one cause by a wide margin. The model behind the tile tried to refresh, the refresh fell over, and the tile is now showing stale-or-broken because it could not rebuild. Go to the semantic model settings, look at the refresh history, and you will usually see the failure with an error message attached. Everything below is really about why that refresh failed.

Credentials expired. Data source credentials in Power BI do not last forever. Someone's password changed, a service account got rotated, an OAuth token expired, and now the refresh cannot authenticate to the source. This is enormously common in Australian organisations with sensible security policies, because the very password rotation that keeps you safe is the thing that quietly kills your refresh sixty days later. The fix is to go into the data source credentials and re-enter them. The annoying part is that nothing warns you until the tile breaks.

The gateway is offline or misconfigured. If your data lives on-premises, in a SQL Server in a server room somewhere, Power BI reaches it through an on-premises data gateway. If that gateway machine is off, or the gateway service stopped, or someone patched the server and it rebooted, the refresh cannot reach the data and the tile breaks. We have lost count of the number of "broken dashboard" calls that turned out to be a gateway machine that got switched off during an office move or a Windows update that did not restart the service. Always check the gateway status.

The underlying data or schema changed. Someone renamed a column in the source. A table got dropped and recreated. A view changed its structure. The refresh runs, cannot find the field the model expects, and errors out. This one is nastier because it means the fix is not just re-entering a password, it is repairing the model to match the new source. These tend to happen after a source system upgrade, and they tend to happen with no warning to the Power BI team because the people changing the source have no idea anyone downstream depends on that column.

A measure or calculation is throwing an error. Less common for tiles specifically, but a DAX measure that divides by zero, or references a column that no longer exists, can produce an error that surfaces on the tile. This one you fix in the model itself.

How to actually diagnose one

The practical workflow is short. Open the tile's dashboard, note which tiles are broken and whether they all come from the same semantic model, because that pattern tells you a lot immediately. If every broken tile traces back to one model, the problem is that model's refresh, full stop. If broken tiles are scattered across several models, you might be looking at a gateway that serves all of them, or a broader outage.

Then go straight to the semantic model and open its refresh history. Read the actual error text. Power BI's refresh errors are more helpful than the tile errors, and they will usually name the problem directly, something like a credentials failure or a specific column not found. Fix the cause, trigger a manual refresh to confirm it works, and the tiles will heal on the next refresh cycle. Sometimes you need to give it a nudge or wait for the cache to rebuild, but the tile follows the model.

The mistake I see people make is trying to fix the dashboard. They delete the tile and re-pin it, and because a re-pinned tile does a fresh render, it might briefly look fixed, which convinces them they solved it. They did not. The next scheduled refresh fails again for the same underlying reason, the tile breaks again, and they are back where they started, now also confused about why their fix did not hold. Fix the refresh, not the tile.

Stopping it happening in the first place

Reactive troubleshooting is fine, but the better answer is not being surprised by these at all. There are a few things we set up for clients so that a broken tile is caught before the board sees it rather than after.

Refresh failure notifications are the obvious one and hardly anyone turns them on. Power BI can email you when a scheduled refresh fails. That single setting turns "the executive noticed the dashboard is broken" into "the data team fixed it before anyone logged in". Turn it on for every business-critical model. It is free and it changes everything about how these incidents feel.

Beyond that, credential and gateway monitoring matters. If you know a service account rotates every ninety days, you can plan for it instead of being ambushed. If your gateway is business-critical, it should be on a machine that does not get casually switched off, and ideally in a gateway cluster so one machine going down does not take the whole thing out. These are the sorts of resilience decisions that separate a reporting setup that quietly works from one that generates a support ticket every fortnight, and they are a core part of how we run managed Power BI and data services for the teams we work with.

For organisations where reporting genuinely underpins decisions, we tend to treat the whole refresh chain as a monitored system rather than a set-and-forget schedule. That is the mindset shift that matters. Your dashboards are only as reliable as the least reliable link between the source data and the tile, and tile errors are just that weakest link making itself known. Getting the business intelligence foundation right is what stops the 8:41am email arriving in the first place.

The honest summary

Tile errors look scary and are almost always mundane. The tile is a cached snapshot, the snapshot could not rebuild, and the reason it could not rebuild is nearly always a failed refresh caused by expired credentials, an offline gateway, or a changed source. Check the model's refresh history first, read the real error, fix the cause upstream, and turn on failure notifications so you find out before your CEO does.

If you want the full mechanics, the Microsoft troubleshooting guide is the reference. And if you are tired of Monday morning surprises and want someone to make the whole refresh chain boringly reliable, get in touch. Boring and reliable is exactly what a dashboard should be.