A Power BI refresh reports success but the dashboard still shows yesterday's numbers — how do you diagnose it?

## "Success" is a statement about the job, not the data A green refresh in the Power BI Service means the semantic model's queries ran and the model was reloaded without error. It does not mean the source held new rows, that the model you are looking at is the one that refreshed, or that the visual in front of you is showing the model's current state. Every stale-data incident is one of those three gaps. ## Step 1 — make freshness visible Before debugging anything, instrument. Add measures like `Data as of = MAX('Sales'[OrderDate])` and, if your warehouse stamps loads, `Source loaded = MAX('Load Log'[LoadedAt])`, and put them on the report page. Now "is it stale" is answered by the report itself rather than by cross-referencing a refresh history. This is also the artifact that ends the argument with the data engineering team about whose side is late. ## Step 2 — confirm which model you refreshed The most common cause in a mature tenant is duplication. Someone republished a full `.pbix` and created a second semantic model; the report you are viewing is bound to that copy, while the schedule you are proudly pointing at belongs to the original. Check the report's lineage and the refresh history of the model the report actually uses, not the one with the familiar name. The durable fix is one governed model with live-connected reports. ## Step 3 — check the timing against upstream Scheduled refresh fires on a clock; your ETL finishes when it finishes. If the warehouse load slipped past the refresh window, the refresh read yesterday's table and succeeded. Symptoms: the model is exactly one cycle behind, every day, or intermittently on heavy days. Fixes: trigger refresh *from* the pipeline when the load completes (via the REST API, or the XMLA endpoint on dedicated capacity) instead of guessing a time; or schedule with real slack and alert on the freshness measure rather than on refresh failure. Also beware time zones: refresh schedules and the timestamps shown in the Service are governed by configured/UTC time, so an apparently recent "last refreshed" reading can be misread by several hours. ## Step 4 — check the refresh scope **Incremental refresh** partitions a fact table by a date range and reprocesses only the recent partitions on each run. That is exactly what you want for performance — and exactly why a late-arriving or back-dated correction in an older period never appears. The data is not stale in the "nothing ran" sense; the changed rows were outside the refreshed window. Confirm the policy's refresh window, and remember that fixing history requires a full refresh of those partitions, not another scheduled run. A related scope issue: if the model's Power Query steps filter to a hard-coded date or read a file whose name embeds a date, refresh cheerfully reloads the same rows forever. ## Step 5 — check the presentation layer Distinguish the three surfaces: - **Report visual (import model):** queries the loaded model, so after refresh it is current — but a browser session opened before the refresh keeps its rendered results until reloaded. - **Dashboard tile:** a cached snapshot. Tiles update after the underlying model refreshes, and the cache update is not instantaneous, so a tile trailing the report page for a short window is expected behaviour, not a bug. If a tile is stale for hours, suspect the model, not the tile. - **Dedicated-capacity query caching:** where enabled, repeated report queries can be served from cache; the cache is invalidated on refresh, but this is worth ruling out explicitly when only some users see old numbers. And the mirror-image case: with **DirectQuery**, there is nothing to refresh at all — data comes from the source per query — so a "scheduled refresh" on such a model refreshes only its cached elements and tiles. Someone insisting DirectQuery data is stale because refresh did not run has misdiagnosed the architecture; the staleness is in the source or in a cache. ## Step 6 — check for a silently partial success Some sources return an empty result rather than an error when a permission or filter goes wrong: a service account loses access to one table, the query returns zero rows, and refresh "succeeds" with an empty or unchanged table. Row-count checks per table, compared against the previous run, catch this class before users do. ## What a strong answer sounds like "I'd first make freshness a measure on the page. Then: which model actually refreshed — is the report on a duplicate? Did the ETL land before the schedule? Is incremental refresh only touching recent partitions while the change is historical? Is this a cached dashboard tile trailing the report? Long term I'd stop scheduling on a guessed clock, trigger refresh from the pipeline, and alert on the freshness measure rather than on refresh status — refresh success and data correctness are different signals."