Microsoft Fabric Architecture Podcast

Real-Time Dashboard puts an alert button on every tile and confirms the save every time. We trace how the Kusto-native monitoring surface actually queries, how its permission model quietly separates viewing from querying, and where the alerting pipeline silently stops evaluating.

Show Notes

Real-Time Dashboard: When 10-Second Refresh Changes the Architecture

Episode 19 • 2026-05-08

Real-Time Dashboard is not Power BI wearing a different hat. Matthias and Fabia unpack the naming collision, permission separation, Activator alert traps, and when you should actually use Power BI DirectQuery instead.

What we discuss

  • A real-world mistake from a pre-Fabric era
  • The one question that reframes the architectural debate
  • How we got here — predecessor products and evolution
  • Why the "obvious" answer is often wrong
  • A real Reddit/Microsoft Q&A question unpacked
  • The concrete recommended architecture
  • F-SKU realism — what this actually costs
  • When the rejected approach is actually right
  • Risks of the recommended path
  • What Microsoft is shipping that changes the calculus
  • The architectural principle to take home

Key takeaways

  • If someone asks 'what's happening right now' — Real-Time Dashboard.
  • But you lose permission separation. You lose tile-as-query simplicity. And your team will absolutely blame the network when the DirectQuery report takes four seconds to load at scale. Different tools, different tradeoffs.
  • Fair argument. Power BI can connect to KQL via DirectQuery. You get DAX measures, RLS, the full semantic model. And in Premium, automatic page refresh goes as low as five seconds. So if your team already lives in Power BI — that's a legitimate path.

Watch the episode

The Fabric Friday video on this topic: https://youtu.be/A_AFcP40K8E

Resources

About the show

Built on ElevenLabs voice synthesis. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.

Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.

Submit your case

Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.


Built on ElevenLabs voice synthesis. Brand design based on fabricperiodictable.com.

What is Microsoft Fabric Architecture Podcast?

Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.

The Alert That Saved Successfully
Episode 19 | 2026-05-08
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia

---

[00:08] Matthias: Three things in Fabric do the dashboard job. Only one refreshes every ten seconds.

[00:13] Fabia: And that one puts an alert button on every single tile.

[00:17] Matthias: So you'd think the alerts just work.

[00:19] Fabia: Today we're pulling apart Real-Time Dashboard — the Kusto-native monitoring surface that looks like Power BI from the outside and behaves like a completely different product underneath. How it actually queries, how its permission model separates viewing from querying, and where the alerting story quietly falls apart.

[00:40] Fabia: A Real-Time Dashboard tile is a single KQL query wired to a visual. No semantic model, no DAX, no Power Query layer between you and the data. You write KQL, the Kusto engine runs it against your Eventhouse or KQL Database, and the result renders. Every tile is independent — each one hits the database on its own refresh cycle.

[01:02] Matthias: So there's no model cache helping you. Every tile is a live query.

[01:06] Fabia: And it's not even fixed-interval polling anymore. Live refresh watches the ingestion high-water mark and only re-queries a tile once new data actually lands. The editor sets a refresh rate limit — a floor so a firehose of ingestion doesn't trigger a query storm — plus a fallback interval for tiles that can't detect ingestion directly. Viewers can pause it or resume it, but they're not tuning the granularity themselves.

[01:35] Matthias: Sounds fast until you're on a factory floor.

[01:38] Fabia: It does. For genuine sub-second control loops — autonomous systems, high-frequency trading — you'd hit the KQL query API directly or read from an Eventstream endpoint. But the honest question is whether a human actually acts on sub-second signals. If someone's reaction time is measured in seconds anyway, shaving the detection lag doesn't change the outcome. Optimize the alert action speed, not the refresh mechanism.

[02:05] Matthias: The part that keeps catching people off guard is the permission model. Everyone assumes sharing a dashboard means sharing database access.

[02:15] Fabia: Two modes. Pass-through identity — the viewer authenticates against the KQL Database. No access, no data, tile errors out. That's the default, matches what Power BI people expect. But the second option catches architects off guard. Dashboard editor's identity. The editor registers an OAuth cloud connection, and the dashboard queries using that credential for every viewer. Anyone with view access sees the data, even without KQL Database permissions.

[02:45] Matthias: That's the executive dashboard use case right there. Leadership watches the operational picture without anyone granting them query access to your production data.

[02:56] Fabia: Or customer portals. Vendor dashboards. Any audience that should see the monitoring view without running arbitrary KQL.

[03:04] Matthias: And then nobody documents who owns the cloud connection, and —

[03:08] Fabia: Ninety days. That's how long a cloud connection survives without use. One morning, every viewer of that executive dashboard sees errors, and whoever's on call burns an hour discovering that a connection nobody remembers creating has expired. No documented warning, no documented grace period. Write down who owns the connection and set your own reminder — the platform won't. Just tiles that stop loading.

[03:35] Fabia: A listener wrote in with something that walks right into this. 'I set up an Activator rule from a Real-Time Dashboard tile. It saved successfully. The condition is being met in the data — I can see the spike on the dashboard. But the alert never fires. What am I missing?'

[03:54] Matthias: I keep running into this exact pattern. The dashboard looks perfect. The spike is right there on the tile. The alert saved without a complaint. And it just... doesn't exist.

[04:06] Fabia: Because the save succeeded. That's what makes it dangerous. Activator lets you create the rule, confirms it, stores it — and then never evaluates it. No warning, no error state, no indication anything's wrong.

[04:20] Matthias: Wait — it saves a rule it knows it can't evaluate?

[04:23] Fabia: It saves it. The validation gap is real. Most common cause: tile type. Activator only evaluates eight visual types — the standard charts plus stat and multi stat. If you built a Map tile or a Table, the rule saves and never triggers. Silent.

[04:39] Matthias: Silent failure on a monitoring tool.

[04:41] Fabia: And then there's the sneaky one — make-series in the query. It's an explicit, documented limitation: Activator doesn't evaluate tiles built on make-series output. Saves fine, never fires, no error. The fix is to rewrite with summarize and bin — same visual result on screen, different data shape underneath, and now the evaluator can actually fire.

[05:05] Matthias: Same chart. Different query. Completely different alerting behavior.

[05:09] Fabia: Then there's custom time ranges — Activator only supports the predefined options. A custom window saves fine, never fires. Same with recipients. External or guest email addresses silently fail — only internal Entra tenant addresses work. And above ten thousand events per second on a single rule, Activator kills it outright.

[05:31] Matthias: Here's what I'd actually tell a team starting their first Real-Time Dashboard. Begin with Stat tiles for your KPIs. They're alert-compatible by default, there's no make-series trap waiting for you, and they're the most readable tile type on a NOC wall from fifteen feet away. Get your alerting pipeline confirmed before you touch Map tiles or fancy visuals. The prettiest dashboard in the world is useless if the alert that's supposed to wake someone at three in the morning never fires.

[06:04] Fabia: On cost — Real-Time Dashboard requires Fabric capacity. An F-SKU. Pro licenses alone don't cover it. And if you want Copilot generating tiles from natural language, that needs F2 or higher on a paid SKU. Trial SKUs don't qualify. For teams outside the US and EU, the tenant admin also needs to flip the cross-region Azure OpenAI processing toggle, or Copilot simply won't appear in the tile editor.

[06:31] Matthias: So the evaluation path is broken before it starts. You spin up a trial, Real-Time Dashboard works beautifully. You try Copilot — nothing shows up. You assume it's a bug. It's a SKU gate that nobody surfaced.

[06:44] Fabia: And the capacity cost itself adds up, but only in the scenario that actually bites you — the fallback path. If a tile can't detect ingestion and falls back to a fixed interval, twenty tiles on a ten-second fallback is two queries per second, sustained. Under normal Live refresh, tiles only query when new data actually lands — quiet periods cost you almost nothing. Set the fallback interval and the refresh rate limit conservatively, and let Live refresh do the cost-saving work it's built for.

[07:17] Fabia: And we should be honest about scope. Real-Time Dashboard can't read Lakehouse Delta tables — that's Power BI with Direct Lake. If you need DAX measures or row-level security, that's Power BI Report. Printable PDFs, mobile-optimized layouts — Power BI again. Real-Time Dashboard does one thing: operational monitoring on Kusto-backed data with fast refresh.

[07:41] Matthias: The test I use is one question. If someone's asking 'what's happening right now,' it's Real-Time Dashboard. If they're asking 'what happened last quarter,' it's Power BI. And in practice, most organizations end up running both side by side. The same KQL Database feeds a Real-Time Dashboard for the ops team and a Power BI report via DirectQuery for the analysts. They partition the work. The naming collision just makes people think they're competing.

[08:12] Fabia: And the team that tries to force one tool into the other's job wastes more time than the team running two dashboards.

[08:20] Fabia: The risk that won't surface in any demo is the ninety-day cloud connection expiry. Set a sixty-day calendar reminder the day you create that connection. Pattern dictates platform — and this platform demands a maintenance calendar that's nowhere in the feature list.

[08:37] Matthias: The bigger lesson here goes past this one dashboard. Silent success is worse than loud failure. A rule that saves and never evaluates. A cloud connection that dies without notification. A Copilot button that's just absent. Every one of those is a team losing half a day to something that should've been a red banner on the save dialog.

[09:00] Fabia: Somewhere right now, there's a dashboard with a clear spike on screen and an Activator rule saved underneath it — confirmed, stored, doing absolutely nothing.

[09:10] Matthias: And someone's sleeping through it.

[09:13] Fabia: If you've hit one of those quiet failures, or you've found a workaround we missed —

[09:18] Matthias: DM me on LinkedIn — find me as Matthias Falland.

---

End of episode. ~09:21 estimated.