How to Check Incremental Refresh in Power BI Service

Setting up incremental refresh feels like a win, but how do you know it's actually working once you've published to the Power BI service? Answering that question is crucial for keeping your reports fast, efficient, and reliable. This guide will walk you through exactly how to check if your incremental refresh is running as expected, plus what to do when it isn't.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

First, What Exactly is Incremental Refresh? A Quick Refresher

Before diving into the "how-to," let’s quickly recap what incremental refresh does and why it's so important for anyone working with large datasets in Power BI.

Imagine you have a report that tracks daily sales data over the last five years. Each time you refresh the report, a full refresh would require Power BI to delete all existing data for your sales table and reload every single row from the past five years. If you have millions or even billions of rows, this process is incredibly slow and puts a heavy load on both your data source and the Power BI service.

Incremental refresh solves this problem. Instead of reloading the entire dataset, it only refreshes the most recent data - the "increment" of new information since the last refresh. Meanwhile, the historical data remains archived and untouched.

Think of it like updating a huge encyclopedia. A full refresh is like reprinting all 26 volumes every single day. Incremental refresh is like getting a small pamphlet with just yesterday's new information and adding it to the collection. It's much smarter and more efficient.

The Benefits of Getting it Right

• Faster Refreshes: Your reports will update a lot faster because you’re only processing a small slice of data. A refresh that once took an hour might take just a few minutes.
• Reduced Resource Load: It places less strain on your source database (like your SQL server) and reduces consumption of your Power BI capacity resources.
• Increased Reliability: Smaller data refreshes are less likely to fail due to timeouts or network interruptions. This makes your reporting more dependable.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

The Groundwork: Setting Up Incremental Refresh

To check if incremental refresh is working, you first need to have it set up correctly in Power BI Desktop before publishing. This setup process is what gives the Power BI service the instructions it needs to partition your data. Here are the core components:

1. Create the Required Parameters

Incremental refresh relies on two special, case-sensitive parameters you must create in the Power Query Editor:

• RangeStart
• RangeEnd

These act as placeholders that the Power BI service will use to define the date range for each incremental update.

To create them:

1. In Power BI Desktop, go to "Transform data" to open the Power Query Editor.
2. Click "Manage Parameters" in the Home ribbon, then "New Parameter."
3. Create RangeStart. Set its Type to Date/Time. Give it any date as a Current Value, like 1/1/2023 12:00:00 AM.
4. Repeat the process for RangeEnd. Set its Type to Date/Time and give it a different Current Value, like 1/31/2023 12:00:00 AM.

Crucially, both parameters must be the Date/Time type, even if your underlying data column is just a date.

2. Filter Your Data Using the Parameters

With your parameters created, you need to apply them as a filter on the primary date column of the table you want to incrementally refresh (e.g., your OrderDate or TransactionDate column).

1. In the Power Query Editor, select the table you want to configure.
2. Click the filter arrow on your date column (e.g., OrderDate).
3. Go to Date/Time Filters > Custom Filter...
4. Set up the filter with two rules:

This filter tells Power BI to only load data that falls between the RangeStart and RangeEnd values. When you publish a report, the Power BI service will dynamically change these values for each new partition it needs to refresh.

3. Configure the Refresh Policy

The final step in Power BI Desktop is to define the incremental refresh policy for your table.

1. Close the Power Query Editor and apply the changes.
2. In the main Power BI window, go to the Model view or the Fields list on the right.
3. Right-click the table you configured and select "Incremental refresh."
4. Enable the policy and set your values. For example:

This configuration tells Power BI to keep five years of historical data and to only refresh the last ten days' worth of data each time a scheduled refresh runs.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

How to Check That Incremental Refresh is Working in The Service

Once you've published your report, the initial data load will be a full refresh, grabbing all the historical data you defined (five years in our example). All subsequent scheduled refreshes should be incremental. Here’s how you verify they actually are.

Method 1: Check the Refresh History

The simplest way to get a high-level confirmation is to review the dataset's refresh history in the Power BI Service.

1. Navigate to the workspace where you published your report.
2. Find your dataset (it has an orange icon). Click the ellipses (...) next to it and select Settings.
3. Under Dataset settings, click on Refresh history.

Here you'll see a log of all manual and scheduled refreshes. Pay close attention to the Duration column.

• The very first refresh after publishing will take a long time, as it loads your full historical data.
• Subsequent refreshes (Scheduled or On-demand) should be significantly faster.

If you see the duration drop from, say, 45 minutes on the first refresh to just 3 minutes for every one thereafter, that's a very strong indicator that incremental refresh is working correctly. If every single refresh takes 45 minutes, it means a full T-SQL table scan is still occurring, and you have a setup issue.

Method 2: Analyze Refresh Metrics Using a Premium Capacity

If you're using a Premium capacity (P, EM, or A), Microsoft provides a free app to monitor your capacity metrics, which can give you more granular detail.

1. Install the Power BI Premium Capacity Metrics app from AppSource.
2. Connect the app to your capacity.
3. Open the app and navigate to the Datasets page of the report.

Look for your dataset in the list and analyze the "Refresh Duration" and "Avg Refresh Duration" metrics. You can also see "Refresh waits," which helps identify if refreshes are queuing up. Here, too, you're looking for a pattern of one long initial load followed by reliably short subsequent refreshes. This is more of a monitoring and performance-tuning tool but serves as excellent validation.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Method 3: Peek Under the Hood with SQL Server Profiler (Advanced)

This is the most definitive way to prove incremental refresh is working, but it's also more technical. It involves connecting to your dataset’s XMLA endpoint and "spying" on the queries Power BI is running against your source data.

This requires either Power BI Premium Per User or a Premium Per Capacity license.

1. Get Your XMLA Endpoint: In the Power BI Service, go to your workspace Settings > Premium > Workspace Connection. Copy this URL.
2. Connect with SQL Server Management Studio (SSMS): Open SSMS, choose "Analysis Services" as the server type, paste in your XMLA endpoint URL, and authenticate with your Power BI credentials.
3. Start a Profiler Trace: In SSMS, connect to the dataset. Right-click the server name in the Object Explorer, choose "Profiler," and start a new trace. Configure the trace to capture "Query Begin" and "Command Begin" events.
4. Trigger a Refresh in Power BI: Go back to the Power BI service and manually trigger a refresh for your dataset.
5. Analyze the Trace: Watch the events in SQL Server Profiler. You will see the actual queries being sent from Power BI to your data source.

If your incremental refresh is working correctly, you will see a SQL query that contains a WHERE clause filtering on the date range for your current incremental partition (e.g., WHERE [OrderDate] >= '2023-11-20T00:00:00' AND [OrderDate] < '2023-11-30T00:00:00'). If you see a simple SELECT * FROM tbl_sales with no date filter, then you have a misconfiguration and a full refresh is occurring.

Troubleshooting: Why Isn't My Incremental Refresh Working?

If you discover that every refresh is a full data load, here are the most common culprits:

• Query Folding is Broken: Incremental refresh requires query folding. This is Power Query's ability to translate your transformation steps into a single SQL statement that can be executed by the source database. If a transformation breaks query folding (like using a "Custom Column" with complex M code), then Power BI has to load the entire table before it can apply the date filter. Make sure your date filtering step is done as early as possible in your Power Query transformations (preferably right after source connection). Right-click on the filtering step and see if the "View Native Query" option is available to confirm it's being folded.
• Incorrect Parameter setup: Double-check that your parameters are named precisely RangeStart and RangeEnd (case-sensitive) and are both set to the Date/Time data type. A typo here will cause the setup to fail.
• Data source does not support query folding: While most relational databases (SQL, Oracle) work great, some data sources like flat files (Excel, CSV) cannot fold queries. Incremental refresh won't work on these types of sources.

Final Thoughts

Verifying that your Power BI incremental refresh is working properly is a key step in managing scalable and efficient reports. By checking your refresh history for shorter durations and, for more advanced cases, using tools like SQL Server Profiler to inspect the actual queries, you can be confident your reports are running optimally.

This process of setting up ETL pipelines, managing data warehouses, and monitoring refreshes is powerful but can be a heavy lift. It's often where teams spend hours wrestling with data instead of finding insights. That's why we’ve built Graphed to completely automate this. By connecting your sources like Google Analytics, Salesforce, or your databases in a few clicks, we handle the data pipelines, refreshes, and warehousing for you so dashboards are always live and you can just ask in plain English what you want to see. Your team gets the answers they need instantly without needing a data engineering degree.