Fabric Capacity Alerts That Actually Fire: Real-Time Hub Over Metrics App

An F64 capacity running at $8,409.60 per month PAYG (as of June 2026) throttles your entire tenant the moment its smoothed CU debt crosses a threshold — and the Capacity Metrics app, your primary visibility tool, has no built-in way to tell you before users start seeing errors. The answer to fabric capacity alerts is a two-minute Activator setup against Real-Time hub capacity events, not a rule wired to the Metrics semantic model. This article gives you the exact recipe: why the Metrics-model path misfires, which event fields to watch, and the grouping trick that prevents alert storms. For the broader monitoring landscape, see the Microsoft Fabric capacity monitoring guide.

The Metrics app has no alert engine

The Capacity Metrics app is the operational source of truth for CU utilization and throttling over the last 14 days — but it is a dashboard, not an alerting system. It has no native mechanism to send an email, a Teams message, or a webhook when a throttling stage begins. The only built-in alert in the Fabric admin surface is the capacity notification email, configured under Admin portal > Capacity settings > Notifications (Configure Power BI Premium capacity notifications, Microsoft Learn, checked June 2026). That email fires when the capacity crosses a raw utilization percentage threshold — checked every 15 minutes, with a 3-hour cooldown after each notification. Two structural problems make this insufficient for throttling detection:

1. The check runs every 15 minutes, so the email can arrive well after the interactive-delay window has already passed into interactive rejection.
2. The 3-hour cooldown means a single early-morning spike can suppress all alerts for the rest of the morning, even if the throttle persists or recurs.

The Microsoft documentation notes that "after a notification is sent, there's a three-hour period in which new notifications won't be sent, even if your capacity crosses thresholds" (Configure Power BI Premium capacity notifications, Microsoft Learn, checked June 2026). For a capacity where the interactive-rejection window is 10–60 minutes of smoothed debt, a 3-hour notification blackout is not an alerting system — it's an incident log.

Why alerting on the Metrics semantic model misfires

The Capacity Metrics app is backed by a Power BI semantic model that refreshes on two cadences: dimension data (capacities, workspaces, item names) refreshes nightly at midnight local time; CU metrics data becomes "available within 10 to 15 minutes after the activity occurs" (What is the Microsoft Fabric Capacity Metrics app?, Microsoft Learn, checked June 2026). A Data Activator rule that reads from this semantic model inherits those lags.

The practical consequence: if you wire Activator to a Power BI visual on the Metrics report — the "Create alert" path available from any visual in the service — Activator polls the semantic model. The capacity could move from interactive delay through interactive rejection before the semantic model refreshes and the rule evaluates. You'll get an alert reporting a throttle that already resolved, or no alert at all because the model hasn't refreshed yet. For monitoring a state that unfolds over a 10-to-60-minute window, a 10-to-15-minute data lag plus evaluation overhead leaves too little room to act.

This is the core problem the Real-Time hub path solves: it sources directly from capacity telemetry, not from a batch-refreshed model.

The reliable-alerting recipe: Real-Time hub capacity events

Fabric capacity overview events are the only near-real-time native signal for capacity health. An active capacity emits a Microsoft.Fabric.Capacity.Summary event every 30 seconds carrying smoothed CU metrics and all three throttling threshold percentages (Explore Fabric capacity overview events, Microsoft Learn, checked June 2026). A Microsoft.Fabric.Capacity.State event fires when the capacity changes state — active, overloaded, or paused.

The summary event schema includes the fields you actually need for actionable alerting:

These percentages are expressions of future-capacity time windows committed by smoothed debt — not raw utilization percentages. A value of 110% on interactiveRejectionThresholdPercentage means 110% of the next 60 minutes of capacity is already spoken for, which is why interactive requests are being rejected. This is the throttling-as-time-windows mechanic described in the Fabric throttling triage guide.

Step-by-step: set the alert from Real-Time hub

The fastest path is the set-alert shortcut directly from Real-Time hub (Set alerts on Fabric capacity overview events, Microsoft Learn, checked June 2026):

1. In Fabric, go to Real-Time hub and select Fabric events.
2. Hover over Capacity overview events and select Set alert (or select the ellipsis and choose Set alert).
3. In the Monitor section, choose Select source events and connect to Microsoft.Fabric.Capacity.Summary for the capacity you want to monitor. Do not set a filter in the connection dialog.
4. In the Condition section, set Check to On each event grouped by, set Grouping field to capacityId, choose the measure (for example, interactiveDelayThresholdPercentage), and select a numeric change condition — not a simple greater-than. Set the threshold (80 is a reasonable production value for early warning).
5. Set the Action to email or Teams message. Select Create.

The numeric-change condition is the critical detail. Because capacity events fire every 30 seconds, a simple greater-than condition floods your inbox for the entire duration throttling persists. A numeric-change condition fires once when the value crosses the threshold, then stays silent until the value drops below the threshold and crosses it again — a single alert per throttle event (Set alerts on Fabric capacity overview events, Microsoft Learn, checked June 2026).

Alternative: build directly in Activator

If you want more control — multiple conditions, custom email body with the actual percentage, or a Teams adaptive card — create an Activator item directly:

1. In your workspace, select New item > Activator.

2. In the Activator canvas, select Get data, search for Capacity Overview Events, and connect.

3. For event type, select Microsoft.Fabric.Capacity.Summary; set event scope to By capacity and select your capacity. Under Set filters, add a pre-filter on data.interactiveDelayThresholdPercentage > 20 (low for testing; raise to 80–90 for production).

4. Select New rule, set condition to On every value, action to Email, and in the message body reference @interactiveDelayThresholdPercentage so the email shows the actual value.

   Warning: "On every value" fires an alert every 30 seconds for as long as the field stays above the filter threshold — the same storm pattern described above. The pre-filter does not suppress repeat events; events keep arriving at 30-second intervals regardless. To suppress repeats, open the Activator rule editor after saving and change the condition from On every value to a numeric-change condition. This way the alert fires once when the value crosses the threshold and stays silent until it drops below and crosses it again.

5. Select Save and start.

The Activator item persists as a Fabric artifact in your workspace. You can update the rule, add more conditions (for example, a separate rule for background rejection), or change the action to a pipeline trigger without rebuilding the event source connection.

The enemy this defeats: the throttling blast-radius

Every workload on a Fabric capacity draws from one shared CU pool. When one workload's smoothed debt crosses a throttling threshold, all workloads on the capacity hit that stage — the attribution void means you can't always tell which workload caused it, and the blast-radius means everyone feels it. Workspace-level surge protection shipped in preview (January 2026), but it throttles or limits a workspace's background usage against an admin-set threshold rather than giving each workspace a guaranteed CU reservation, so tenant-wide blast radius still applies for interactive workloads.

The throttling stages, as time windows not utilization percentages (checked June 2026 against Understand your Fabric capacity throttling, Microsoft Learn):

Proactive alerting on interactiveDelayThresholdPercentage at 80% gives you roughly 10–15 minutes to act before rejection starts. That window is enough to triage the throttle and scale the capacity up, or kill the rogue workload, before users notice. With the Metrics app alone — 10-to-15-minute data lag, no alert engine — you're always behind the window.

Two failure modes to know before you deploy

Paused capacities go dark. When a capacity is paused, it emits no summary events (Explore Fabric capacity overview events, Microsoft Learn, checked June 2026). If you're auto-pausing to save cost, your alerting goes dark at the same time. Wire a separate alert on the Microsoft.Fabric.Capacity.State event (state = Overloaded) to catch the moment a capacity comes back up throttled. Pausing does technically reset an active throttle — but it pushes all smoothed background debt into the next active window, billing the overage immediately at PAYG rates. On reserved capacity, you pay the reservation plus the overage. Pausing to clear throttling is expensive; it is not a remedy.

Best-effort delivery means gaps are possible. The Microsoft documentation is explicit: capacity summary events use best-effort delivery, meaning rare drops or duplicates can occur (Explore Fabric capacity overview events, Microsoft Learn, checked June 2026). Duplicates can be de-duplicated with summarize take_any(*) by windowStartTime, windowEndTime, capacityId in KQL. Missing events have negligible impact on alerting (one missed 30-second window doesn't suppress the next), but they matter if you're persisting events to an Eventhouse for graphing — sample max over 5-minute windows to smooth over gaps. For continuous history, persist to Eventhouse early; the system does not backfill.

What to set up, in order

1. Set the Real-Time hub alert on interactiveDelayThresholdPercentage with a numeric-change condition grouped by capacityId, threshold at 80%. This is your primary early-warning signal.
2. Add a second rule on interactiveRejectionThresholdPercentage at 80% — this is the critical alert that fires just before users see errors.
3. Wire a separate alert on the Microsoft.Fabric.Capacity.State event (state = Overloaded) to catch the moment a capacity enters throttling — including capacities that resume after a pause. Note that a resumed capacity starts with zero carry-forward debt (debt was billed at pause time as a one-time settlement), so the Overloaded event will only fire if new workloads immediately re-accumulate debt after resumption.
4. Persist summary events to an Eventhouse from the same Real-Time hub connection. The Fabric capacity events deep-dive shows the Eventhouse storage pattern. This gives you the carry-forward debt history the Metrics app drops after 14 days.
5. Do not pair these alerts with an auto-pause action. If you auto-pause on throttle, the debt is billed immediately and the capacity goes dark to your alerting. The correct response to an alert is to investigate, scale up if needed, or terminate the rogue workload.

Frequently asked questions

Does the Fabric Capacity Metrics app have built-in alerts? No. The Capacity Metrics app has no native alert engine. It shows CU utilization, throttling stages, and top-consuming items for the last 14 days, but it does not fire an email or Teams message when throttling starts. Capacity admins can configure a separate email notification in the Admin portal that fires when capacity usage crosses a percentage threshold, checked every 15 minutes with a 3-hour cooldown — but that fires on raw utilization, not on the actual throttling stages users experience.

What is the most reliable way to get Fabric throttling alerts? The most reliable path is Real-Time hub capacity overview events wired to a Data Activator rule. An active Fabric capacity emits a Microsoft.Fabric.Capacity.Summary event every 30 seconds carrying interactiveDelayThresholdPercentage, interactiveRejectionThresholdPercentage, and backgroundRejectionThresholdPercentage. Set an Activator rule grouped by capacityId with a numeric-change condition on the relevant percentage field, and you receive a single alert the moment the threshold is crossed — not a flood of repeated notifications.

Why is wiring Data Activator to the Capacity Metrics semantic model unreliable for alerts? The Capacity Metrics semantic model refreshes on a scheduled basis — nightly for dimension data and approximately every 10 to 15 minutes for CU metrics. That lag means an Activator rule reading from the semantic model sees stale data. By the time a throttling event appears in the model and triggers a rule, users may already be experiencing interactive rejection or background rejection. Real-Time hub capacity events are the only near-real-time signal, emitted at 30-second intervals directly from the capacity.

How do I avoid alert storms from Fabric capacity events? Use a numeric-change condition in Activator, grouped by capacityId. Capacity overview events fire every 30 seconds while a capacity is active, so a naive greater-than condition sends an alert every 30 seconds for the entire duration throttling persists. A numeric-change condition fires once when the metric crosses the threshold, then stays silent until the metric drops below the threshold and crosses it again. The Microsoft documentation explicitly warns against threshold-only conditions for this reason.

What fields should I alert on in Fabric capacity overview events? Alert on interactiveDelayThresholdPercentage for early warning (interactive delay starts when this exceeds 100%), interactiveRejectionThresholdPercentage for the threshold where users see errors (interactive rejection when this exceeds 100%), and backgroundRejectionThresholdPercentage for critical pipeline failures (background rejection when this exceeds 100%). The overageTotalCapacityUnitMs field tells you the size of the carry-forward debt, which is useful for estimating how long the throttle will last.

Researched with AI assistance, written and fact-checked by Jonathan Flach, verified against Microsoft Learn.