Setting Up Automatic Page Refresh in Power BI for Real-Time Dashboards

Most Power BI dashboards do not need to be live. The monthly board pack, the sales pipeline review, the finance reconciliation - none of them care whether the numbers are three seconds old or three hours old, and pretending otherwise just burns capacity. But every so often we get a brief where the whole point is that the screen updates on its own. A logistics client wanted a wall-mounted board in the depot showing trucks in and out against the day's target. A manufacturer wanted the line supervisor to see reject rates climb without touching a mouse. An energy client wanted grid load on a big screen in the control room. For those, a report that only updates when someone hits refresh is useless.

That is what automatic page refresh is for, and it is one of those Power BI features that looks trivial in the settings panel and turns out to have real teeth once you understand what it actually does to your data source. Microsoft's reference is Automatic page refresh in Power BI, and it is worth reading. This post is about how we set it up on real client reports, and the parts the docs are quiet about.

The two modes, and why the difference matters

Automatic page refresh lives in the Format pane when you have a report page selected, not a visual. There is a card called Page refresh, and once you switch it on you get two ways to do it.

Fixed interval is the obvious one. You pick a cadence - every 5 seconds, every 30 seconds, every 5 minutes - and Power BI re-runs the queries for every visual on the page on that clock, whether or not anything changed. Simple, predictable, and slightly wasteful. If your interval is 5 seconds and your data lands every 2 minutes, you are hammering the source 24 times for every genuine update.

Change detection is the clever one, and it is the mode people forget exists. Instead of refreshing on a blind timer, Power BI polls a single measure you nominate - a "change detection measure" like the maximum timestamp in your table - and only refreshes the visuals when that measure's value actually changes. So the page checks "has anything new arrived?" cheaply and often, and does the expensive full refresh only when the answer is yes. On a depot board that goes quiet for twenty minutes at lunch, that is the difference between a couple of hundred pointless queries and none.

My honest advice: default to change detection whenever the underlying data has a natural "last updated" marker, which it almost always does. Fixed interval is fine for demos and for sources where you cannot cheaply detect change, but in production it is the blunt instrument.

The requirement nobody reads until it bites them

Here is the bit that catches teams out, and it catches them late, usually the afternoon before a go-live.

Change detection and sub-minute refresh intervals require DirectQuery. They do not work on Import mode datasets. This makes sense once you think about it - Import mode holds a snapshot of the data in the model, and refreshing the page cannot conjure newer rows that were never loaded. Only DirectQuery, which pushes each query back to the source in real time, can actually see the truck that arrived four seconds ago.

And there is a second gate. Sub-minute refresh (anything faster than once a minute) and change detection are only available on Premium / Fabric capacity, not on shared capacity with a standard Pro licence. On shared capacity the fastest you can go is every 30 minutes. The people running the workspace need to know that before they design a "live" board, because "live" and "every 30 minutes" are very different products, and finding out the day before launch is a bad afternoon.

We now ask two questions at the very start of any real-time reporting conversation: is the source a DirectQuery-capable system that can take the query load, and is there Premium or Fabric capacity behind this workspace? If either answer is no, we redesign the expectation before we design the report. That single habit has saved more than one project from an awkward walk-back.

The part that gets underestimated - source load

A dashboard refreshing every 5 seconds on DirectQuery is, from the source system's point of view, a small robot asking the same set of questions all day without ever getting tired. If ten visuals sit on that page, that is ten queries every 5 seconds, forever, per open report. Put that board on three screens across the site and you have tripled it. Now imagine the source is a busy transactional SQL database that the operations team also depends on for the actual business.

We have seen this go wrong. Not catastrophically, but a DBA gets in touch asking why there is a steady drumbeat of identical queries chewing through connections. The report worked beautifully in testing because testing had one viewer. Production had a wall board plus fifteen curious managers who each left the tab open.

So a few things we do as standard. Keep the real-time page lean - the fewer visuals, the fewer queries per tick. Push change detection so the source is only truly hit when data moves. Consider a read replica or a purpose-built serving layer rather than pointing the board straight at the primary transactional database. And be realistic about the interval: a supervisor watching a production line does not need 5-second refresh, they need 30-second refresh that they trust. Faster is not better once it starts costing you database health.

This is exactly the sort of trade-off we work through in our Power BI consulting engagements, because the right refresh strategy is as much an architecture decision as a report setting. The dropdown in the Format pane is the easy 10%. Sizing the source, choosing the capacity, and deciding what "real time" honestly needs to mean for the business is the other 90%.

Where it genuinely shines

I do not want to talk it down, because when the fit is right it is excellent and there is no fuss to it. Operations rooms are the sweet spot. A single big-screen board, a DirectQuery source built for it, change detection watching a timestamp, an interval matched to how fast the data actually moves. Depot throughput. Line performance. Live queue lengths in a contact centre. Grid or asset telemetry. Anything where a human is meant to glance at a screen and react.

The other quiet win is trust. When people see a dashboard update itself, they believe it. A static report that someone has to remember to refresh always carries a nagging "is this current?" question, and in operational settings that doubt is corrosive. A board that ticks over on its own removes the question entirely, and that psychological effect is worth more than the raw feature. Half the value is that nobody wonders whether they are looking at stale numbers.

Where it does not belong

Plenty of reports get automatic page refresh switched on because it feels modern, and it is the wrong call. Executive summaries, analytical reports people read and think about, anything on Import mode, anything where the data source updates a few times a day - none of these benefit, and the refresh either does nothing useful or adds load for no reason. If your data lands hourly via a scheduled dataset refresh, a page refreshing every 5 seconds just re-queries the same snapshot 720 times an hour to show you the identical picture. That is not real time, that is a treadmill.

The tell is simple. Automatic page refresh is worth it only when three things line up: the data genuinely changes faster than a person would manually refresh, the source can serve DirectQuery at that cadence without strain, and a human is actually watching the screen in the moment. Miss any one of those and you are decorating, not solving.

The bigger picture for Australian operations teams

Real-time BI is having a moment locally, and it is not just Power BI. Manufacturers, logistics operators, utilities and mining businesses are wiring up sensors, telemetry and event streams, and they want the shop floor to see it. Automatic page refresh is a good, cheap front end for a lot of that, provided the plumbing behind it is built for real-time work rather than retrofitted onto a nightly batch warehouse.

Increasingly the live dashboard is not the end of the story either - it is the trigger. The same event streams feeding a refreshing board can feed an agent that watches for the reject rate crossing a threshold and raises an alert, or drafts the handover note, without anyone staring at the screen. That crossover between live operational data and AI acting on it is a lot of what we build under AI for business intelligence and across our broader AI for manufacturing work. A well-modelled DirectQuery source is the foundation for both the human-watched board and the machine-watched one.

So if you are setting this up: switch on Page refresh, prefer change detection over a fixed timer, confirm you are on DirectQuery and Premium or Fabric capacity before you promise anyone "live", and have a genuine conversation about what your source can take. Get those right and it just works, quietly, all day. Skip them and you will find out the hard way, usually from your DBA.