Forum Discussion
Advocate ICheck the incremental refresh
Hello,
How can I verify that the incremental refresh has been successfully applied after a dataset refresh?
Are there any logs, indicators, or recommended methods to confirm that the refresh was processed incrementally rather than as a full refresh?
Thank you.
Hi PBI_2K26,
The presence of the partitions confirms that the incremental refresh policy has been applied, but I would not use the partition structure alone as proof that the most recent refresh processed only the incremental window.
Microsoft documents that, after the initial refresh creates the partitions, a normal Power BI Service refresh applies the incremental refresh policy and refreshes only the partitions inside the configured refresh period. The older historical partitions are left unchanged.
The advanced incremental refresh documentation also shows why the distinction matters. With XMLA/TMSL or advanced refresh operations, applyRefreshPolicy can be set to false. In that case, Power BI can fully process all partitions while leaving the existing partition definitions in place.
So:
- existing partitions = the incremental refresh policy has been applied;
- successful Refresh History entry = the model refresh completed;
- neither one alone proves exactly which partitions were queried during that particular refresh.
For a normal scheduled refresh, I would not expect Power BI to silently ignore a valid incremental-refresh policy and fall back to refreshing all historical partitions.If you need to verify the behaviour more rigorously, Microsoft's incremental refresh troubleshooting guidance recommends tracing the source queries. You should see queries for the relevant partitions with their RangeStart / RangeEnd predicates. That lets you verify which date ranges were actually requested from the source during the refresh.
If the model is on Fabric/Premium capacity, you can also inspect the partitions through the XMLA endpoint using SSMS or Tabular Editor. And if you orchestrate refresh through the Enhanced Refresh REST API, the refresh execution details can provide object/partition-level information for that operation.
So for your specific question, I would use Refresh History to confirm that the scheduled refresh succeeded, and source-side query tracing if you need evidence that only the incremental window was actually processed.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
3 Replies
- ShivekMaharaj
Memorable Member
Hi PBI_2K26,
The presence of the partitions confirms that the incremental refresh policy has been applied, but I would not use the partition structure alone as proof that the most recent refresh processed only the incremental window.
Microsoft documents that, after the initial refresh creates the partitions, a normal Power BI Service refresh applies the incremental refresh policy and refreshes only the partitions inside the configured refresh period. The older historical partitions are left unchanged.
The advanced incremental refresh documentation also shows why the distinction matters. With XMLA/TMSL or advanced refresh operations, applyRefreshPolicy can be set to false. In that case, Power BI can fully process all partitions while leaving the existing partition definitions in place.
So:
- existing partitions = the incremental refresh policy has been applied;
- successful Refresh History entry = the model refresh completed;
- neither one alone proves exactly which partitions were queried during that particular refresh.
For a normal scheduled refresh, I would not expect Power BI to silently ignore a valid incremental-refresh policy and fall back to refreshing all historical partitions.If you need to verify the behaviour more rigorously, Microsoft's incremental refresh troubleshooting guidance recommends tracing the source queries. You should see queries for the relevant partitions with their RangeStart / RangeEnd predicates. That lets you verify which date ranges were actually requested from the source during the refresh.
If the model is on Fabric/Premium capacity, you can also inspect the partitions through the XMLA endpoint using SSMS or Tabular Editor. And if you orchestrate refresh through the Enhanced Refresh REST API, the refresh execution details can provide object/partition-level information for that operation.
So for your specific question, I would use Refresh History to confirm that the scheduled refresh succeeded, and source-side query tracing if you need evidence that only the incremental window was actually processed.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- GilbertQ
Super User
Hi PBI_2K26
One of the ways to do this is to use DAX Studio and connect to your semantic model in the Power BI service. Once you have done that you can then run the Vertipaq analyzer which will then have an option to show you the partitions on your tables. You can then see all the partitions that are created based on your incremental refresh policy.
PBI_2K26Hi GilbertQ ,
I can see the partitions created by my incremental refresh policy. Does the presence of these partitions automatically confirm that the most recent scheduled refresh was executed incrementally, or could a full refresh still have occurred?
More specifically, are there any scenarios where the partitions exist and appear correctly, but incremental refresh is not actually being applied during refresh operations (for example, if it silently falls back to a full refresh or if the policy is not being honored as expected)?
Thank you.
