Fabric Capacity Events in the Real-Time Hub: Near-Real-Time Monitoring

An F64 capacity costs $8,409.60 per month at PAYG rates — and by the time your users report load errors, the Capacity Metrics app might be 15 minutes behind the throttle that caused them. Fabric capacity overview events in the Real-Time hub (preview) close that gap: an active capacity emits one Summary event every 30 seconds, letting you alert on throttling before interactive rejection hits your users.

This article is the deep-dive companion to the Microsoft Fabric capacity monitoring complete guide. That pillar maps the full native monitoring stack — the Capacity Metrics app, Chargeback, FUAM, SemPy extracts, and Real-Time hub events — and where each one stops. Here we build the detailed architecture for the events path: what each event carries, how to route it, and how to wire a sub-minute alert that fires before the 60-minute interactive-rejection window fills.

What the Capacity Metrics app cannot do

The Capacity Metrics app's Compute page is the source of truth for CU utilization and throttling over a 14-day rolling window — but "usage 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). It also has no native alerting engine. The moment a capacity starts building carry-forward overage, the metrics app falls behind — and by the time the data refreshes, interactive requests may already be delayed or rejected.

This is the throttling blast-radius problem: one workload's smoothed debt throttles everyone on the shared capacity, and the only native tool that reflects it is already 10–15 minutes stale. Real-Time hub events are the platform's answer. They do not replace the metrics app — they fill the one lane the app structurally cannot: proactive, sub-minute alerting on throttling as it happens.

For a full treatment of the throttling mechanics — future-capacity time windows, the 10-minute interactive-delay boundary, the 60-minute rejection boundary — see Fabric throttling explained. For alerting strategy beyond the event stream, see Fabric cost and throttling alerts.

The two event types

Fabric capacity overview events (preview) emit two distinct event types per capacity (Explore Fabric capacity overview events, Microsoft Learn, checked June 2026):

Two behaviors matter for alerting design. First, a paused capacity emits no Summary events — the event stream goes silent. Second, a healthy capacity emits no State events — a blank State table means implicitly NotOverloaded, not missing data. If you alert purely on State events, you'll miss the carry-forward build-up visible in the Summary's percentage fields before the state actually transitions.

The Summary event's three threshold-percentage fields are the early-warning layer:

• interactiveDelayThresholdPercentage — the average % utilization of the next 10 minutes of capacity (20 smoothing windows). When this exceeds 100%, a ~20-second delay is added to interactive requests.
• interactiveRejectionThresholdPercentage — the average % utilization of the next 60 minutes (120 windows). When this exceeds 100%, interactive requests are rejected outright.
• backgroundRejectionThresholdPercentage — the average % utilization of the next 24 hours (2,880 windows). When this exceeds 100%, all operations are rejected.

These are the same thresholds the Capacity Metrics app displays on its Compute page — but here you get them at 30-second granularity, not with a 10–15 minute lag.

The eventstream-alert architecture

Below is the complete architecture for routing capacity events into persistent storage and sub-minute alerting using only native Fabric components. This is a text diagram — all blocks are Fabric items you create in your workspace.

┌─────────────────────────────────────────────────────────────────────────────┐
│  SOURCE                                                                     │
│  Real-Time Hub → Fabric Events → Capacity Overview Events                   │
│  • Microsoft.Fabric.Capacity.Summary  (every 30 s, per active capacity)     │
│  • Microsoft.Fabric.Capacity.State    (on state transition only)            │
└────────────────────────────────┬────────────────────────────────────────────┘
                                 │ Eventstream (one per capacity or multi-cap)
                                 ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  EVENTSTREAM                                                                │
│  Transform: split Summary events and State events to separate outputs       │
│  (optional but simplifies downstream KQL schema)                            │
└──────────────────────┬──────────────────────────┬──────────────────────────┘
                       │                          │
                       ▼                          ▼
┌───────────────────────────────┐   ┌─────────────────────────────────────────┐
│  EVENTHOUSE (KQL Database)    │   │  DATA ACTIVATOR                         │
│  Table: CapacitySummary       │   │  Source: Summary events                 │
│  Table: CapacityState         │   │  Grouping: by capacityId                │
│  Retention: months/years      │   │  Condition: numeric change on           │
│  (you own the policy)         │   │    interactiveDelayThresholdPercentage  │
│  Dedup: take_any(*) by        │   │    > 80 (numeric change, not per-event) │
│    windowStartTime,           │   │  Action: Email / Teams                  │
│    windowEndTime,             │   │  Fires ONCE when threshold crossed,     │
│    capacityId                 │   │  resets when usage drops below          │
└───────────────────────────────┘   └─────────────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│  KQL DASHBOARD / REAL-TIME DASHBOARD                                        │
│  • Utilization % over time (capacityUnitMs / (baseCapacityUnits * 1000 * 30)│
│  • Overage carry-forward trend (overageTotalCapacityUnitMs)                 │
│  • Workload breakdown (capacityUnitUtilizationBreakdown by workload)        │
│  • State events timeline                                                    │
└─────────────────────────────────────────────────────────────────────────────┘

Why split into Eventhouse AND Data Activator? Because they do different jobs. The Eventhouse stores every 30-second row so you can query history, build trend charts, and catch post-incident forensics — filling the 14-day gap that the Capacity Metrics app leaves. Data Activator holds no history; it evaluates each incoming event against your rule and fires when the threshold is crossed. You need both: the Eventhouse for "what happened and when," Activator for "tell me the moment it starts."

The dedup step in Eventhouse is not optional. The capacity events documentation notes that "events can either fail to be sent, or duplicates might be received" (Explore Fabric capacity overview events, Microsoft Learn, checked June 2026). In KQL, remove duplicates before charting:

CapacitySummary
| summarize take_any(*) by windowStartTime, windowEndTime, capacityId
| extend UtilizationPct = todouble(capacityUnitMs) / (baseCapacityUnits * 1000.0 * 30) * 100
| where UtilizationPct < 500          // exclude pause-flush spikes
| project windowStartTime, capacityId, UtilizationPct,
          interactiveDelayThresholdPercentage,
          interactiveRejectionThresholdPercentage
| render timechart

The < 500 filter matters: when a capacity is paused, all smoothed usage flushes into the next available window, which can produce utilization spikes of up to 288,000% of normal. Those pause-flush artifacts should not drive alerting logic.

Activator rule design: avoiding alert storms

The Microsoft Learn docs make a specific warning about alert frequency: "Capacity overview events fire frequently. If you set an alert that triggers on every event where usage exceeds a threshold, you receive a continuous stream of alerts for the entire duration that usage remains high" (Set alerts on Fabric capacity overview events, Microsoft Learn, checked June 2026).

The correct Activator configuration:

1. Source: Microsoft.Fabric.Capacity.Summary for the target capacity.
2. Grouping: On each event grouped by → field: capacityId. This prevents one alert per 30-second event; instead you get one alert per capacity per threshold crossing.
3. Condition: select a numeric change condition on interactiveDelayThresholdPercentage. Set the threshold to a value meaningful for your operational policy — the tutorial suggests 20% for testing, 80–90% for production.
4. Action: Email or Teams message. The Activator fires once when the value crosses the threshold and resets when it drops below — not once per event.

For the State event path, you can set a separate alert directly from the Real-Time hub's Set alert button on the Capacity overview events detail page, targeting Microsoft.Fabric.Capacity.State events. This gives you a second signal when the capacity actually transitions to Overloaded — a confirmation that what the Summary threshold warned of has crossed into a formal throttle.

What the Summary event payload looks like in practice

Take an F64 capacity with baseCapacityUnits = 64. The per-30-second CU budget is 64 × 1,000 ms × 30 s = 1,920,000 CU-ms. If capacityUnitMs = 2,304,000, utilization for that window is 120% — 20% over budget, meaning 384,000 CU-ms of carry-forward added to overageAddCapacityUnitMs. That carry-forward distributes into future windows.

At an F64 PAYG cost of $8,409.60/month (64 CUs × $0.18/CU-hour × 730 h/month, as of June 2026), each hour of idle costs approximately $11.52. An undetected background rejection — where all jobs are blocked for more than 24 hours of smoothed future debt — can cost that in blocked pipeline runs, failed refreshes, and engineer time, plus the capacity spend that continues regardless. The 30-second event stream makes that scenario detectable before it reaches full rejection.

The capacityUnitUtilizationBreakdown field in each Summary event breaks CU consumption by workload (Spark, Semantic Model, Dataflow, Eventhouse, Data Integration, and more). This breakdown is not the per-item attribution the Capacity Metrics app provides — it's still capacity-level aggregate — but it can tell you which workload type is driving a spike, which is often enough to direct the investigation. For per-item attribution, the metrics app's Compute page is still the right surface.

Setup: four steps

Getting capacity events flowing takes about 15 minutes for a workspace with Contributor or higher permissions and capacity admin access (Get Fabric capacity overview events in Real-Time hub, Microsoft Learn, checked June 2026):

1. In Real-Time hub, select Fabric events → Capacity overview events. Choose your capacity and select Create eventstream. Name it and save.
2. Add an Eventhouse destination. In the Eventstream editor, add a KQL Database destination, select or create your Eventhouse, and map Summary events to a CapacitySummary table and State events to a CapacityState table. Start this before you need the data — the event system does not backfill.
3. Set the Activator alert. From the Capacity overview events detail page, select Set alert. Follow the Activator configuration in the previous section: grouped by capacityId, numeric-change condition on interactiveDelayThresholdPercentage, your chosen threshold.
4. Build a KQL dashboard. Use the dedup + utilization query above to visualize the 30-second history already accumulating in the Eventhouse. Add the State events timeline as a second query for incident annotation.

The feature is in preview as of June 2026 (What's new in Microsoft Fabric, Microsoft Learn, checked June 2026). Validate current availability and any regional limitations in the Microsoft Learn docs before committing to a production alerting design.

The named enemy: throttling blast-radius

This article directly defeats the throttling blast-radius — the enemy where one workload's carry-forward debt throttles the entire capacity and the only native metric showing it is already 10–15 minutes stale. The 30-second Summary stream cuts that lag to under a minute. The State event fires the moment the capacity formally transitions to overloaded.

The blast-radius problem is architectural: there is no native per-workspace CU isolation that prevents one team's workload from throttling everyone else. Workspace-level surge protection (preview, January 2026) can block an individual workspace when its total CU consumption over a rolling 24-hour window exceeds an admin-set threshold, but it does not give each workspace a guaranteed CU reservation — the shared pool and its tenant-wide blast radius still apply. A fast alert lets you respond before interactive rejection sets in, which is the only practical mitigation short of scaling the SKU or fixing the workload.

The correct response when throttling begins is not to pause the capacity. Pausing does technically end an active throttle by resetting the capacity — but it simultaneously flushes all smoothed background and interactive overage into the bill at PAYG rates. On a reserved capacity, you pay the reservation fee plus the flushed overage. Pausing to clear a throttle is a costly trap. The right fix is scale up, fix the query, or schedule the workload differently. For the full throttling-response playbook, see Fabric throttling explained and Fabric cost and throttling alerts.

Frequently asked questions

How often do Fabric capacity overview events fire? Active capacities emit a Microsoft.Fabric.Capacity.Summary event every 30 seconds, carrying smoothed CU usage, the interactive-delay and interactive-rejection threshold percentages, and a workload breakdown. A separate Microsoft.Fabric.Capacity.State event fires only when the capacity changes state — for example, becoming overloaded (throttling) or being paused. A paused capacity emits no Summary events at all, per Microsoft Learn (checked June 2026).

What is the difference between a Summary event and a State event? A Summary event is a recurring 30-second heartbeat with CU metrics: how much compute was used, how much carry-forward overage is building, and what percentage of the interactive-delay and rejection thresholds are filled. A State event fires on a discrete transition — the capacity becoming overloaded (throttling), being paused, or resuming. If the capacity stays healthy for days, you get only Summary events; the State table remains blank, which per Microsoft Learn means the capacity is implicitly NotOverloaded.

Can I store Fabric capacity events longer than 14 days? Yes. The Real-Time hub events are not subject to the Capacity Metrics app's 14-day compute window. If you route the Eventstream into an Eventhouse (KQL database), you own the retention policy and can keep months or years of 30-second Summary rows — building trend dashboards the app's rolling window cannot produce.

Do Fabric capacity events replace the Capacity Metrics app? No. They serve different purposes. The Capacity Metrics app gives you the authoritative operational view — per-item CU attribution, throttling details, storage tracking — but lags 10–15 minutes and has no alerting engine. Capacity events give you near-real-time signals and the ability to trigger alerts, but carry only capacity-level aggregates, not the per-item breakdown. A solid monitoring stack uses both.

Is the Fabric Real-Time hub capacity events feature generally available? As of June 2026, Fabric capacity overview events in the Real-Time hub are in preview. The feature launched in November 2025 per Microsoft's what's-new archive (checked June 2026). Preview features can change; validate against current Microsoft Learn documentation before building production alerts.

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