How to Safely Automate Fabric Capacity Pause/Resume

An F64 Fabric capacity costs $8,409.60 per month at PAYG rates (64 CUs × $0.18/CU-hour × 730 hours, as of June 2026) — and it bills the same amount whether it is running flat-out or sitting completely idle. If your workload runs in a defined window — a nightly transform, business-hours BI, an end-of-week load — automating pause and resume around that window is the single highest-leverage cost move available. Done correctly, it recovers the idle fraction of that bill outright. Done wrong, it bills you for compute you already smoothed and turns a cost lever into a cost trap.

This article is the safe counterpart to the Fabric pause-resume trap. That piece explains what goes wrong; this one explains how to do it right. The broader cost-reduction playbook that this fits into is in How to reduce Microsoft Fabric costs. For the SKU-sizing step that should precede any pause schedule, see how to right-size your Fabric capacity.

Why there is no native auto-shutdown — and what to use instead

Fabric F-SKU capacities have no built-in idle-timeout, no scheduled auto-shutdown, no native "pause at 11 PM" toggle. Microsoft's documentation confirms that pause and resume are manual or API-driven operations (Pause and resume your Fabric capacity, Microsoft Learn, checked June 2026). You wire the schedule yourself.

Three viable automation paths exist, in rough order of operational weight:

Note: Microsoft Learn documents only the Azure Automation runbook path under "Schedule your operation" (Pause and resume your Fabric capacity, Microsoft Learn, checked June 2026). Logic Apps and Fabric data pipelines can call the same REST API and are community-established approaches, but are not covered in MS Learn capacity-pause documentation.

Microsoft instructs users to search for Fabric in the Azure runbook gallery to find pre-built scheduled pause/resume runbooks (Pause and resume your Fabric capacity — Schedule your operation, Microsoft Learn, checked June 2026).

The underlying calls are two simple Fabric REST API endpoints:

POST /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Fabric/capacities/{capacityName}/suspend

POST /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Fabric/capacities/{capacityName}/resume

(Fabric Capacities — Suspend, Microsoft Learn REST reference, checked June 2026; Fabric Capacities — Resume, checked June 2026.)

The caller needs four Azure RBAC actions on the capacity resource: Microsoft.Fabric/capacities/read, /write, /suspend/action, and /resume/action. Microsoft recommends a custom role scoped to exactly these four rather than a broad privileged role (Pause and resume your Fabric capacity — Prerequisites, Microsoft Learn, checked June 2026).

The pause trap: why the order of operations matters

Before running through the safe-automation checklist, understand the one mechanism that makes naively automating pause risky.

Fabric smooths consumption forward in time so that short bursts don't immediately throttle users. Interactive operations smooth over a minimum of 5 minutes, and up to 64 minutes for heavy operations; background operations smooth over a 24-hour period, distributed across 30-second timepoints (Understand your Fabric capacity throttling — Smoothing, Microsoft Learn, checked June 2026). Separately, throttling triggers when a capacity exhausts its next 10-minute window of future capacity — that threshold is a throttling stage, not the smoothing duration itself. That means at any moment a capacity may be carrying accumulated future-capacity usage that hasn't been billed yet.

Pausing settles all of it at once. Microsoft's documentation is unambiguous: "When you pause your capacity, the remaining cumulative overages and smoothed operations on your capacity are summed, and added to your Azure bill" (Pause and resume your Fabric capacity, Microsoft Learn, checked June 2026). The Capacity Metrics app confirms the mechanism: "When you pause your capacity, the accumulated smoothed usage and any overages are converted to utilization and billed to you" — and a spike appears in the utilization chart when this happens (Monitor a paused capacity, Microsoft Learn, checked June 2026).

On a PAYG capacity, pausing with outstanding smoothed debt bills that debt at full PAYG rates. On a reserved capacity, the situation is worse — the reservation keeps billing regardless, and the smoothed overage bills at PAYG on top. Automated pause/resume is a cost lever only for PAYG capacities. For reserved, the equivalent lever is automating SKU resizing up and down.

The throttling docs make the mechanism explicit: "Pausing a capacity results in a billing event for the accumulated future capacity usage. When a capacity starts or resumes, it has zero future capacity usage so it can accept new operations right away" (Understand your Fabric capacity throttling, Microsoft Learn, checked June 2026). That last sentence is why some teams consider pausing to clear throttling — but the first sentence is why it's a trap. The throttling clears; so does your wallet.

The safe-automation checklist

This is the article's original material: a sequenced checklist that addresses the real failure modes, with the REST suspend/resume pattern embedded at the right step. Work through it top-to-bottom before automating any schedule.

Step 0 — Verify this is PAYG, not reserved

Check your capacity's billing model in the Azure portal. If it is a reserved capacity, automated pause/resume provides no billing benefit — the reservation charges continue. Stop here and switch to the SKU-resizing automation path instead.

Step 1 — Map your actual active window from Capacity Metrics

Open the Microsoft Fabric Capacity Metrics app and pull 14 days of compute data. Find the last timepoint each day where CU utilization is non-zero. Your pause should land after the last pipeline finishes and your resume should land before the first job starts — not at a guessed clock time.

Look at the Background operations chart specifically. Background jobs smooth over 24 hours, so a pipeline that ran at 10 PM may still carry smoothed debt at 2 AM. The safe pause window is after a genuinely quiet stretch, not just after the UI shows no active sessions.

Step 2 — Check for active sessions immediately before pausing

Microsoft's guidance is explicit: "Before you pause your capacity, make sure the capacity is not being used" (Pause and resume your Fabric capacity, Microsoft Learn, checked June 2026). Build this check into your automation logic, not just your runbook documentation.

In a runbook or Logic App, query the Capacity Metrics semantic model (via XMLA/REST) or call the Fabric REST API to check capacity state before issuing the suspend call. The capacity state endpoint (GET .../providers/Microsoft.Fabric/capacities/{capacityName}) returns a state field; only proceed with suspend if the capacity is Active and your usage telemetry confirms it is quiet.

If your automation finds activity, skip the pause for that cycle. This is the guard rail that protects against pausing mid-pipeline.

Step 3 — Verify smoothed background debt is clear (or acceptable)

Check the Capacity Metrics app's Background rejection chart: this shows the 24-hour smoothed background percent. If that figure is materially above zero, the capacity is carrying forward-smoothed background debt. Pausing now bills that debt.

The practical rule: only schedule pauses after a confirmed quiet window where background jobs have not run for the duration you are willing to accept as risk. For a nightly transform that finishes at 1 AM, a pause scheduled for 2 AM with a resume at 6 AM gives a four-hour pause window with at most one hour of post-job smoothing risk. For maximum safety, push the pause to after the full background smoothing window has cleared.

You can also check the carryforward percent directly: on the Metrics app Compute page, open the Overages section, or drill through to any recent timepoint and read the Burndown table Cumulative % column. If Cumulative % is 0%, no smoothed carryforward exists and the pause is safe.

Note: The SKU card hover-tooltip that shows cumulative carryforward percent — described in the Monitor a paused capacity doc (checked June 2026) — is a post-pause diagnostic. It requires navigating to a paused-capacity spike timepoint and only appears after a pause has occurred. It is not available on a live, running capacity, so it cannot be used as a pre-pause check.

Step 4 — Issue the suspend call

Only after Steps 1–3 confirm safe conditions: POST to the suspend endpoint. The minimal Azure CLI invocation (in a runbook):

az rest --method post \
  --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{rgName}/providers/Microsoft.Fabric/capacities/{capacityName}/suspend?api-version=2023-11-01" \
  --headers "Content-Type=application/json"

Or use the pre-built Azure Automation runbook from the gallery, which wraps this in error handling and logging.

After issuing the call, the Capacity Metrics app's System Events table will show the capacity state as Suspended (Monitor a paused capacity, Microsoft Learn, checked June 2026). Note: if the capacity was in an overloaded state when you paused, the table may show an Active NotOverloaded event immediately after the Suspended event — the capacity is still paused, this is expected behavior.

Step 5 — Resume with enough lead time

POST to the resume endpoint with enough lead time before your first job. Resuming billing and content availability happen together:

az rest --method post \
  --url "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{rgName}/providers/Microsoft.Fabric/capacities/{capacityName}/resume?api-version=2023-11-01" \
  --headers "Content-Type=application/json"

"Resuming your capacity also resumes billing. Content assigned to this capacity becomes available once the capacity is resumed" (Pause and resume your Fabric capacity, Microsoft Learn, checked June 2026). Build in a buffer — typically five minutes — between the resume call and the first scheduled pipeline or report refresh.

Step 6 — Validate and iterate

After the first automated cycle, open the Capacity Metrics System Events table and confirm the Suspended and Active events appear at the expected times. Check that the utilization spike at pause time is proportional to your smoothed debt (if any). If the spike is much larger than expected, you paused with more carry-forward than you thought — revisit the timing in Step 1.

The dollar math: what safe automation actually recovers

The recoverable amount is the idle fraction of the capacity's PAYG bill. For PAYG (as of June 2026):

These are estimates based on 64 × $0.18 = $11.52/hr for F64, scaled down for smaller SKUs, assuming 12 idle hours per day with a clean pause (zero smoothed debt). Actual recovery depends on how clean your pauses are and how many idle hours your window contains. Every hour of smoothed debt billed at pause time reduces the net recovery for that cycle.

The 12-hours-per-day figure is illustrative. A workload that genuinely runs only between 7 AM and 11 PM can pause for eight hours; one that runs a single nightly two-hour transform can pause for 22 hours and recover more than 90% of the capacity's monthly bill.

The named enemy this defeats

The enemy this article defeats is the pause trap — but specifically its safe side. The pause trap has two faces: the obvious face (pausing to clear throttling, which bills the debt immediately) and the silent face (automating pause without clearing smoothed debt, which has the same effect on a schedule). Safe automation means designing the schedule so the silent face never fires.

The throttling blast-radius — where one greedy background job's 24-hour smoothed debt fills the whole capacity and delays the pause — is the mechanism that makes Step 3 non-optional. You cannot skip the carryforward check and assume a quiet window is clean.

Frequently asked questions

How do you automate Fabric capacity pause and resume? Call the Fabric REST API suspend endpoint to pause and the resume endpoint to start. Schedule these calls via Azure Automation runbooks — the path Microsoft Learn documents — or, via the same REST API, a Logic App or Fabric data pipeline (not covered in MS Learn documentation for this use case). The Microsoft Learn pause-resume doc instructs users to search for "Fabric" in the Azure runbook gallery to find pre-built pause/resume runbooks (checked June 2026).

Is there a native auto-shutdown for Microsoft Fabric F-SKUs? No. F-SKU capacities have no built-in scheduled pause or idle-timeout. You must wire the schedule yourself using Azure Automation, Logic Apps, or the REST API. This is confirmed in Microsoft's pause-resume documentation (checked June 2026).

What happens to smoothed debt when you pause a Fabric capacity? All accumulated smoothed usage and overages are converted to utilization and added to your Azure bill immediately at PAYG rates. Microsoft states this explicitly in the pause-resume documentation (Microsoft Learn, checked June 2026). Pausing does immediately end throttling, but it converts all outstanding smoothed debt into a lump PAYG billing event — a costly trap, especially on reserved capacity where the overage hits at full undiscounted PAYG rates on top of the ongoing reservation fee.

How long before pausing should you let the capacity run quiet? Background operations smooth over a 24-hour rolling window. If you want zero smoothed background debt at pause time, the capacity needs a full 24-hour quiet window with no background jobs running. In practice, most teams pause during a confirmed off-hours window where pipelines have completed and verify the Burndown table Cumulative % reads 0% on the Compute page before issuing the suspend call.

Can you automate pause/resume on a reserved Fabric capacity? You can pause a reserved capacity but there is no billing benefit — the reservation charge continues whether the capacity is running or not, and any smoothed overage at pause time bills at PAYG rates on top. Automated pause/resume is a cost lever for PAYG only. On reserved capacity, use the schedule to size up for peak windows and size down between them instead.

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