PAYG Overage Billing (2026): What It Changes for Your Forecast

An F32 Fabric capacity costs $4,204.80 per month at PAYG rates, and a team that enables capacity overage can watch that estimate blow past $5,000 in a single bad week — without anyone pausing anything or scaling a SKU. That is the specific risk the new overage billing model introduces to monthly forecasting, and most budget models do not account for it.

PAYG overage billing in Microsoft Fabric is an opt-in feature (currently in preview) that automatically pays off capacity usage above your SKU's smoothed limit — preventing throttling — at 3 times the standard pay-as-you-go rate, billed through a separate Azure meter. It does not require you to pause the capacity or trigger a settlement event. It runs silently while the capacity is active, and it appears on your invoice as a line distinct from your baseline compute. For the complete picture of how native monitoring surfaces this, see the Microsoft Fabric capacity monitoring guide. This article focuses specifically on what the overage billing model does to your monthly forecast and how to model it accurately.

What "PAYG overage billing" actually is

Before 2026, the only two billing events that produced a charge above your baseline SKU were: (a) pausing a capacity with outstanding smoothed debt, which settled the overage as a one-time PAYG charge, and (b) scaling up to a larger SKU temporarily, which charged PAYG for the higher tier. Throttling itself produced no bill — it just degraded user experience.

Capacity overage billing changes that. When the feature is enabled by a capacity admin (F SKUs only, as of June 2026), the platform automatically pays off any CU usage that crosses the interactive-delay threshold — the point at which smoothed usage for the next 10 minutes exceeds 100% of the SKU's capacity — rather than throttling users. The billing mechanism, per Microsoft Learn:

"When enabled, capacity overage charges at 3 times the pay-as-you-go rate, limited only to usage that exceeds your current capacity and would otherwise trigger throttling." — Capacity overage (preview), Microsoft Learn (checked June 2026)

Azure routes this charge through a separate meter labeled "Capacity Overage Capacity Usage CU" — distinct from your baseline capacity meter. It does not inflate the baseline line; it adds a new line. That separation is consequential for forecasting: the baseline line is predictable; the overage line is not.

Two additional mechanics shape the risk:

1. Capacity overage pays off the current time window but does not clear future debt. If the same overloaded workload keeps running, overage billing keeps firing until the 24-hour rolling limit you set is exhausted — at which point standard throttling resumes.
2. Enabling overage during an active throttling event charges all cumulative carry-forward immediately. If a capacity is already in an interactive-delay or rejection state when an admin turns on overage billing, the platform bills all the accrued debt at once at 3× PAYG.

Reserved capacity does not cover overages

The most common forecast mistake with the overage model is assuming the reservation discount extends to overages. It does not. Capacity overage always charges at 3× the pay-as-you-go rate — the reservation discount applies to the SKU's baseline CUs only; CU usage beyond the reserved allowance is charged at full PAYG rates (Enable capacity overage (preview), Microsoft Learn, checked June 2026).

With capacity overage enabled, the effective overage rate is 3× PAYG — no reservation discount. On a reserved F64 ($5,002.87/month, as of June 2026):

• Baseline: covered by the reservation at the discounted rate.
• Overage CU-hours: billed at $0.18 × 3 = $0.54 per CU-hour, regardless of the reservation.

A reserved F64 running a sustained 20% overage for 8 hours generates: 64 CUs × 20% × 8 h = 102.4 CU-hours of overage × $0.54 = $55.30 in a single session, on top of the reservation fee. Extrapolate that to 13 sessions per month (three times a week, ~4.3 weeks) and the monthly overage line reaches ~$719 — without the capacity ever throttling, without anyone pausing, and without the reservation discount softening the hit. The "effective" F64 cost in that scenario is ~$5,722, not $5,003.

The overage limit: your only spending control

The capacity admin sets a rolling 24-hour CU-hours spending limit when enabling overage billing. This is the only guard rail. Once the limit is exhausted, overage billing stops and throttling resumes. The limit is checked every 5 minutes, which means it is possible to slightly exceed your configured cap before the next check fires (Enable capacity overage, Microsoft Learn (checked June 2026)). The throttling stages that resume once the overage limit is exhausted — interactive delay (10–60 minutes), interactive rejection (60 minutes–24 hours), and background rejection (beyond 24 hours) — are governed by the same smoothing windows documented in the throttling reference (checked June 2026).

Microsoft recommends keeping the limit below one-third of your daily CU-hours allowance — the point at which overage costs become comparable to scaling up to the next SKU. The reasoning is mechanical:

Overage cost per CU-hour:  $0.54  (3× PAYG)
Next-SKU cost per CU-hour: $0.18  (PAYG baseline)
Overage is 3× baseline — so 1 CU-hour of overage ≈ 3 CU-hours of baseline
If overage exceeds 1/3 of daily SKU allowance, scaling up is cheaper

For reference, the daily CU-hours allowances (from Microsoft Learn, checked June 2026):

Above one-third, a SKU upgrade is cheaper than sustained overage billing. Below one-third, overage acts as a shock absorber for occasional spikes. The limit is configurable in multiples of 48 CUs.

The forecast-impact worked example

This is the forecast-impact-worked-example asset — a side-by-side forecast model showing how enabling capacity overage changes a monthly bill versus the default throttle behavior.

Scenario: A mid-size analytics team runs an F32 PAYG capacity. The capacity regularly hits 130% of baseline during a two-hour afternoon BI peak (a large semantic model refresh plus concurrent report queries). Without overage billing, this produces interactive delay for those two hours — users see a ~20-second lag on report interactions. With capacity overage enabled at 240 CU-h/day (the highest valid setting below the one-third threshold; limits must be multiples of 48 CU-hours), those two hours are paid off instead.

Variables (all June 2026 PAYG, estimated):

• Overage intensity: 30% above F32 baseline = 32 × 0.30 = 9.6 CU above baseline per hour
• Overage duration: 2 hours/day × 22 working days = 44 overage-hours per month
• Overage CU-hours: 9.6 × 44 = 422.4 CU-hours/month
• Overage rate: $0.18 × 3 = $0.54/CU-hr

All figures are estimates. Baseline assumes F32 PAYG running 730 hours; OneLake at 40,000 GB × $0.023. Overage computed from CU-hours above SKU limit × $0.54. As of June 2026.

Three things this table makes concrete:

1. The "no overage" scenario is not free. Throttling produces no billing line, but it costs real money in degraded analyst productivity and deferred pipeline runs. The overage feature converts that hidden cost into a visible one — which is actually useful for FinOps.
2. The overage line is proportional to the gap, not the total. At 30% above baseline for 2 hours/day, the monthly overage is $228 — a 4.4% premium on the base compute line. At 60%, it doubles to $456. This is forecastable if you know your CU consumption profile.
3. The limit is your circuit breaker. If you set the 24-hour overage cap at 240 CU-hours (the highest valid setting below the one-third threshold; limits must be multiples of 48 CU-hours), the worst-case daily overage charge is: 240 CU-h × $0.54 = $129.60/day, or ~$3,888 worst-case for a 30-day month at the cap every calendar day. That is the hard ceiling for this SKU with overage enabled — exceeding it returns the capacity to standard throttling.

The old forecasting model had two lines: baseline compute and OneLake storage. Overage billing adds a third line that is neither flat nor zero. Forecasting it correctly requires knowing your peak consumption profile from the Capacity Metrics app — specifically the smoothed utilization chart — and applying a probability-weighted scenario to the overage line.

The named enemy: the invisible overage bill

The enemy this article defeats is a variant of the attribution void — specifically, the invisible overage line. Capacity overage billing runs silently, appears on a separate Azure meter, and is entirely absent from most vendor cost calculators. Teams that enable it as a "safety net against throttling" — without modeling the cost impact — discover the premium on their monthly invoice and have no log of which workloads triggered it.

The Capacity Metrics app surfaces overage history: it logs processed overages, shows CU-hours billed, and indicates capacity state (Active vs. Throttling). Azure Cost Management exposes the separate "Capacity Overage Capacity Usage CU" meter for tracking financial impact. Neither tool alerts you proactively when you are approaching the 24-hour limit — for that, you need either a Power Automate flow querying the Capacity Metrics semantic model, or a continuous monitoring layer that watches the overage meter in real time.

What to do with the 2026 overage model

The decision to enable capacity overage is not primarily a performance decision — it is a budget decision. Here is how to make it correctly:

1. Model your CU peak before enabling overage. Pull 14 days of compute detail from the Capacity Metrics app and find the smoothed utilization chart. If the 10-minute interactive smoothed line regularly exceeds 100%, you have a throttling candidate. Quantify the magnitude: 110% baseline × 2 hours is very different from 200% baseline × 6 hours.

2. Calculate the break-even against scaling up. Use the one-third-of-daily-CU-hours rule. For an F32 (768 CU-h/day), the theoretical break-even is around 256 CU-h/day of overage — the nearest valid limit setting (multiples of 48 CU-hours) is 240 CU-h/day. If your sustained peak would push past that limit regularly, scaling to an F64 ($4,204.80 vs. $8,409.60/month PAYG) may cost less than sustained overage billing. The full SKU comparison lives in choosing between reserved and PAYG capacity.

3. Set the 24-hour limit conservatively first. Start at one-third of your SKU's daily CU-hours. This caps the worst-case overage premium and ensures you are alerted (by throttling restarting) before the bill compounds further.

4. Add the overage line to your monthly estimate model. The three-line Fabric bill — compute, storage, overage — now needs all three modeled to give you an accurate forecast. The baseline estimate methodology is in how to estimate your monthly Fabric bill; add the probability-weighted overage scenario as a fourth column.

5. Set an Azure budget alert on the overage meter. In Azure Cost Management, filter by the "Capacity Overage Capacity Usage CU" meter and set a daily budget alert at 80% of your intended cap. That alert fires before the limit is reached, giving you time to investigate and scale if needed.

6. Never enable overage as a substitute for right-sizing. Microsoft's own documentation flags this: if you are regularly hitting overage, scale up — do not rely on the overage feature to absorb structural under-provisioning at 3× the rate. Overage is designed for occasional spikes, not sustained mismatches between workload and SKU.

Frequently asked questions

How does PAYG overage billing work in Microsoft Fabric? When capacity overage is enabled (a preview opt-in feature for F SKUs), any usage that exceeds your SKU's smoothed limit — and would otherwise trigger throttling — is automatically paid off and billed at 3 times the normal pay-as-you-go rate via a separate Azure meter. You set a rolling 24-hour CU-hours spending limit; once that limit is reached, overage billing stops and standard throttling resumes. As of June 2026 per Microsoft Learn, this feature is in preview.

Does a reserved Fabric capacity cover overage billing? No. A capacity reservation is a billing commitment for your SKU's baseline CUs — it does not extend to overages. Any CU usage beyond the reserved SKU's allowance is billed at full pay-as-you-go rates (or, if capacity overage is enabled, at 3× the PAYG rate). You pay the reservation fee plus the PAYG-rate overage with no reservation discount applied to the excess.

What is the 3× overage rate in Microsoft Fabric? When capacity overage is enabled, Microsoft bills excess CU usage at 3 times the pay-as-you-go rate — $0.18 × 3 = $0.54 per CU-hour for the portion above your SKU's allowance, as of June 2026. Microsoft recommends keeping the 24-hour overage limit below one-third of your daily CU-hours, the point at which the overage cost becomes comparable to scaling up to the next SKU.

How does PAYG overage billing change a monthly Fabric forecast? It adds a third unpredictable line to a forecast that most teams only model in two: baseline compute and storage. Overage billing is proportional to the gap between your actual CU consumption and your SKU's allowance, then multiplied by 3. A single runaway workload that sustains 130% of an F32's baseline for two hours per day can add over $200/month in overage charges — without the capacity ever throttling users or triggering a pause-settlement.

What is the difference between capacity overage billing and the pause-settlement overage? These are two distinct billing events. Capacity overage billing (the preview feature) activates automatically while the capacity is running, billing at 3× PAYG for CU-hours that would otherwise trigger throttling. It requires opt-in by a capacity admin. Pause-settlement overage happens whenever you pause a capacity with accumulated smoothed debt — all outstanding future-capacity usage is summed and billed at full PAYG rates, regardless of whether capacity overage is enabled. Pause-settlement applies on both PAYG and reserved capacities; capacity overage billing is F-SKU-only and requires explicit activation.

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