Power BI Relative Time Slicers - Filtering Reports to the Last Few Minutes

May 20, 2026•8 min read•Michael Ridland

A few months back a client asked me a question that comes up surprisingly often. They had a Power BI dashboard showing operational data refreshing every minute, and they wanted the visuals to only show "the last five minutes" of activity. Not the last day. Not the last hour. The last five minutes, ticking along.

The standard date slicer in Power BI does not help here. It works in days, weeks, months. You can't ask it to show the last 90 seconds of data. So if you've ever tried to build a near-real-time operations dashboard, you've probably bumped into this limitation.

The fix is the relative time slicer. It looks similar to the relative date slicer but works in minutes and hours. Combined with automatic page refresh, it gives you something close to a live dashboard inside Power BI. Not perfect, but workable for a lot of operational use cases I've seen at Australian companies, especially in logistics, manufacturing, and customer service.

Microsoft has documentation on relative time slicers that explains the mechanics. What follows is what I'd tell you over a coffee if you were about to build one for the first time.

Where this actually matters

Before getting into the how, it's worth being honest about when this feature is useful. The relative time slicer is built for fast refresh scenarios. If your data refreshes once a day, you do not need minute-level filtering. You probably want the standard date slicer instead.

But there are real cases where this is genuinely useful:

A call centre dashboard showing inbound calls over the last 30 minutes
A warehouse dashboard showing pick rates by zone over the last hour
A manufacturing line dashboard showing OEE in the last 15 minutes
A web operations dashboard showing checkout failures over the last 5 minutes

We've built variations of all of these for clients. The pattern is always the same. There's a streaming or near-streaming data source feeding a DirectQuery model in Power BI, automatic page refresh ticks every 30 seconds or every minute, and a relative time slicer keeps the window pinned to "the last X minutes." The result feels like a live operations screen, which is what people want on the wall.

If you're thinking about building this kind of dashboard, our Power BI consulting work covers exactly this sort of thing, and we usually start with a careful conversation about whether Power BI is really the right tool versus a proper streaming dashboard built on Fabric Real-Time Intelligence.

Getting the slicer set up

The mechanics are straightforward. Drag a date or time column onto the canvas, switch the visual to a slicer, then go into the Format pane. Under Visual, Slicer settings, Options, change the Style to Relative Time. You then get a control that lets you pick Last, Next, or This, a number, and a unit of Minutes or Hours.

There are two non-obvious bits worth flagging.

First, the column you bind to has to be a date/time type, not a date type. The relative time slicer needs the time component to do its job. If your fact table has a column called EventDate that's just a date, the slicer will not work properly. You need a EventDateTime or similar. Sounds obvious in writing but I've seen people lose half a day trying to figure out why their slicer is showing nothing.

Second, the relative time slicer works in your data model's time, not the user's local time. We'll get to that.

The anchor time concept

This is where the documentation is technically correct but not quite practical enough. When you apply a relative time filter at the page or report level, Power BI uses what Microsoft calls an "anchor time." Every visual on the page calculates its "last 5 minutes" relative to the same anchor, not relative to whenever that individual visual happens to execute its query.

Without this, you'd get drift. Visual A queries the database at 10:00:00 and shows the last 5 minutes. Visual B queries at 10:00:02 and shows a slightly different last 5 minutes. The visuals would not line up. People would notice and lose trust in the dashboard.

The anchor time refreshes on initial load, manual refresh, automatic page refresh, and model changes. Practically speaking, this means if you have automatic refresh set to every 60 seconds, every minute all your visuals are recalculated against the same anchor. Good behaviour, and one of those features that just works without you having to think about it.

The exceptions are worth knowing. The Q&A visual ignores the anchor time until you convert it to a standard visual. And a relative date filter on the same page ignores the anchor unless there's also a relative time filter on the page, in which case the date filter joins the party. Bit of a quirk. In practice we just avoid mixing Q&A visuals into operational dashboards.

Time zones and the UTC trap

Here's where it gets ugly. Power BI data models do not store time zone information. Times are just times. The relative time slicer always evaluates against UTC.

If you're sitting in Brisbane and your data is in AEST, "last 5 minutes" is fine because the relative window is the same size regardless of time zone. But the moment you have visuals showing actual time stamps next to a relative slicer, you'll notice the times on the visuals are in UTC and your users will get confused.

The pragmatic fix is to convert times to local time in your Power Query step on the way in, or use a calculated column. If your data is genuinely global, pick a single time zone, store everything in that, and label your visuals clearly so users know what they're looking at. Trying to do per-user time zone display in Power BI is a fast way to lose a week of your life. I have learned this lesson personally.

For Australian organisations operating across time zones, the simplest approach is usually to convert to Sydney time (AEST/AEDT) on ingest and accept that's the canonical time. Yes, daylight savings will cause a small amount of weirdness twice a year in Queensland reports. Most clients can live with this if you flag it upfront.

Where this combines with other Power BI features

The relative time slicer is most useful paired with automatic page refresh and DirectQuery. The combination looks like this. Your data lands in a SQL backend or a real-time analytics database. Power BI connects via DirectQuery. The page is set to refresh every 30 or 60 seconds. The relative time slicer is set to "Last 5 minutes" or whatever your window is. Visuals re-query on each refresh and always show the most recent window of data.

There's a hidden cost here. Every refresh runs queries against your data source. If you have 8 visuals on a page and refresh every 30 seconds, that's 16 queries per minute against the database from a single user. Multiply by 20 concurrent users and you can start hammering the source. Make sure whatever sits behind it can handle the load. Usually this means either an analytics-tuned database like Synapse or Fabric, or aggressive caching at the source.

If you're going down this path properly we usually recommend a quick architecture review of the whole stack rather than just bolting it onto whatever already exists. Our AI for business intelligence practice tends to look at the full picture, partly because once you've got near-real-time data flowing, there's a natural conversation about whether AI can do something useful with it.

The query cache gotcha

One last thing the documentation mentions almost in passing but is worth highlighting. Power BI uses the client cache aggressively. If you change the relative time slicer from "last 1 minute" to "last 5 minutes" and then back to "last 1 minute," you may see the cached results from the first query, not freshly queried data.

This rarely matters in production because the page refresh forces a recalculation. But in development, you can think you're seeing live behaviour when you're actually seeing cached behaviour. If something looks weird, do a manual refresh or close and reopen the page before getting into debugging mode.

When not to use this

To finish on an honest note. The relative time slicer is great for what it is, but it's not magic. If you need sub-second updates, Power BI is probably the wrong tool entirely. Look at proper streaming dashboard tools, or Fabric Real-Time Intelligence with KQL queryset visuals.

If your data refreshes every 15 minutes from an SAP extract, the relative time slicer is overkill. A standard date slicer will do.

And if you find yourself building 10 dashboards with relative time slicers because everyone wants their own real-time view, take a step back. Real-time dashboards are easier to build than they are to sustain. Someone has to keep the data flowing, keep the source database happy, and respond when the auto-refresh stops working at 2am because the gateway service restarted. Build them where they earn their keep, not just because you can.

If you want a hand thinking through whether this approach fits what you're trying to do, get in touch. We've done enough of these to have opinions and we're happy to share them.

Reference

The Microsoft source for this feature is at Create a relative time slicer or filter in Power BI.