The Stop Button That Doesn't Stop Episode 20 | 2026-05-15 Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia --- [00:08] Matthias: Fabric Activator has a Stop button. You press it, the status column says Stopped. [00:13] Fabia: Every week, someone in the Fabric forums asks why they're still being billed. [00:18] Matthias: For a stopped rule. [00:19] Fabia: Today we're pulling apart Activator's entity model — the layer underneath the no-code surface that decides whether your alerting works, or just looks like it does. [00:30] Fabia: Eventstream and Eventhouse handle ingestion and storage. Activator sits on top — it subscribes to data already in motion and evaluates rules. The interesting part is the entity model underneath. Events arrive from a source — sensor readings, transactions, status changes. Activator groups them into objects by a shared identifier like device ID or customer number. Then it tracks properties on those objects — temperature, balance, status — retaining the last value per object for seven days. And the rules evaluate conditions against those property changes, per object, continuously. [01:09] Matthias: Wait — each rule tracks state independently for every single object? [01:14] Fabia: Every instance. A thousand freezers, a thousand independent state machines. Freezer forty-two crosses a threshold while forty-three is fine — the rule fires for forty-two alone. [01:25] Matthias: That's a different thing from a KQL query. A query gives you a snapshot of everything that matches right now. This is a running state machine per entity. [01:36] Fabia: And this is where teams get burned the first week. A stateless rule — value greater than twenty-five — fires on every event where temperature exceeds that mark. Sensor reports every five seconds, the package stays at twenty-six degrees for an hour, that's seven hundred and twenty emails in your inbox. [01:56] Matthias: I've seen that inbox. [01:57] Fabia: A stateful BECOMES greater than twenty-five fires once on crossing the threshold. Package stays at twenty-six for an hour? Still one alert. Drops below and crosses back? Second alert. The state machine prevents repeated firings within unchanged conditions. [02:14] Matthias: The stateful evaluation costs more per event — there's a separate computation meter for it. But teams who go stateless to save fractions of a CU end up paying in ops credibility instead. Once your alerting channel is noise, nobody reads it. I'd rather pay the computation charge and have alerts that mean something than save a fraction of a cent and watch the on-call engineer tune out by Thursday. [02:41] Fabia: We got a question that hits the thing most teams discover too late. "I created a test rule, ran it for a day, then hit Stop. A week later I see Activator capacity usage in the Metrics App. Why am I still being charged when the rule isn't running?" [02:58] Matthias: The weekly thread. [03:00] Fabia: When you create a rule and connect it to a data source, Activator spins up an event listener — a persistent connection to receive events. Press Stop, and the rule stops evaluating conditions and firing actions. But the listener stays warm — [03:16] Matthias: Still billing. [03:17] Fabia: A touch over two hundredths of a CU per hour, per rule. And the only way to stop that charge is deletion. Even then, there's a propagation delay — up to five minutes where the rule can still fire actions after you've clicked Delete. [03:32] Matthias: I get the design rationale — keeping the listener warm means restart is instant. But a Stop button that doesn't stop billing is a support ticket every single time. Every team I've worked with discovers this once. The ones that don't check their capacity metrics discover it for months. [03:51] Fabia: The rule uptime charge is the quiet accumulator. But on high-volume streams, the ingestion meter usually does more damage — 0.000011111 CU per event. Doesn't sound like anything. A stream doing two thousand events per minute is a hundred and twenty thousand per hour. Over a month, that's real capacity you're burning on events Activator receives, evaluates, and discards. [04:16] Matthias: And the lever is filtering before events reach Activator? [04:20] Fabia: Microsoft's docs show the exact math. Add a Filter transformation in Eventstream — drop events where status equals OK — and you go from two thousand events per minute to six hundred and sixty-seven. The filter node draws the Eventstream Processor meter on top, so you're trading a flat hourly charge against the ingestion savings. Microsoft's example doesn't do the net math — it only shows the volume falling from two thousand events a minute to six hundred and sixty-seven. Run the numbers for your own stream. You're just choosing not to forward events that Activator would bill you to receive. [05:00] Matthias: That should be the first screen in the setup wizard. [05:03] Fabia: There's a capability most teams overlook entirely when they set up Activator. Everyone defaults to email and Teams for actions. But Activator can trigger Fabric items directly — Pipelines, Notebooks — [05:16] Matthias: It triggers Notebooks directly? So you could wire an ML scoring model to re-evaluate every time a condition fires? [05:24] Fabia: And you can pass context with it — there's a preview feature where you wire the property values that fired the rule into the notebook as parameters. You have to configure that explicitly; it doesn't just happen. [05:38] Matthias: That changes the conversation completely. It's event-driven compute with a no-code detection layer on top. The teams who only know about the email action are using maybe a quarter of what this thing actually does. And that's a wizard-defaults problem. The setup flow steers you toward email, and most people never look past it. [06:00] Matthias: So when should someone skip Activator entirely and just use Power Automate? [06:05] Fabia: When the trigger isn't a data stream. SharePoint file upload, Outlook email, Teams message — Power Automate has over a thousand connectors and richer orchestration. Approval chains, branching, loops, document assembly. Activator detects conditions and fires. The multi-step orchestration belongs in Power Automate. [06:26] Matthias: Which is exactly why the hybrid pattern works. Activator spots the anomaly in the stream, fires a Custom Action that triggers a Power Automate flow, Power Automate creates the ServiceNow ticket or posts to Slack. You're layering detection on top of orchestration. The teams that try to make Activator do both — chaining Fabric item actions into a pseudo-workflow — that's where it gets fragile. [06:52] Fabia: And there's a hard boundary worth naming. Activator is fire-and-forget — there's no return channel. If a caller needs to wait for a result, an Azure Function or a Logic App with an HTTP trigger is the right tool for that job. [07:07] Matthias: The risk that genuinely worries me with Activator isn't the billing — that's manageable once you know the delete rule. It's the governance chain. Custom Actions wrap Power Automate flows. Those flows have connection owners. Cloud connections expire. If the person who created the connection leaves the team, the flow fails silently. The rule still evaluates, the condition still fires, the action goes nowhere — and nobody gets notified that the notification system is broken. That's the scenario I'd audit for quarterly. [07:42] Fabia: Pattern dictates platform. If your pattern is stateful detection on streaming data — per-object state machines, threshold transitions, heartbeat monitoring — Activator is exactly the right tool. If your pattern is reacting when a file lands in SharePoint, you've got the wrong tool in the slot. [08:02] Matthias: And if your pattern is build it, test it, hit Stop, and walk away — check your capacity metrics in a week. [08:09] Fabia: Somewhere in your tenant, right now, there's an event listener attached to a rule somebody stopped months ago. Still warm. Still counting. [08:19] Matthias: If you're sorting this out for your team, DM me on LinkedIn — find me as Matthias Falland. [08:25] Fabia: See you Friday. --- End of episode. ~08:26 estimated.