Never Pay for Idle Azure Fabric Capacity Again: Automate Pausing with Logic Apps!

[cpatra]

This article is authored by Chinmaya Patra Architect at Microsoft

Introduction

I’ve been there too many times—resuming my Azure Fabric capacity for some quick testing or development work, only to forget to pause it afterward. The next thing I know, my Azure subscription bill is higher than expected, all because the capacity kept running unnecessarily. If you’re in a similar boat, this blog post is for you. I’ll walk you through how I set up an automatic solution using Azure Logic Apps and alerts to pause the Fabric capacity after a set time, saving both costs and headaches.

The Problem : The Costly Oversight We All Make

We use a learning Fabric capacity to keep our costs low, especially since we’re on a Pay-As-You-Go (PAYG) plan. The idea is to resume it when we need it and pause it when we’re done. But here’s the catch: I often forget to pause it after finishing my work. This means the capacity keeps running, racking up charges that could easily be avoided. It’s a common issue, and I’m sure I’m not the only one who’s faced it.

The Solution : Event-Driven Automation with Azure Logic Apps

The problem of forgotten Fabric capacity pauses can be effectively solved through automation. The goal is to automatically turn off the capacity after a desired period of work, for instance, two hours from the moment it is resumed. This provides flexibility, allowing the capacity to run only for the necessary duration after it is manually or programmatically activated [User Query].

Azure Logic Apps serve as a powerful and accessible solution for this automation. They provide a low-code infrastructure, making them ideal for building and orchestrating complex workflows without extensive coding. Logic Apps excel at integrating various systems and services, automating multi-step processes, and eliminating the need for manual intervention. While Azure Functions are well-suited for specific compute tasks or lightweight API implementations, Logic Apps, with their rich set of pre-built connectors and visual designer, are generally a more appropriate choice for orchestrating event-driven workflows like this.  

The automated flow for pausing Fabric capacity involves a series of interconnected steps, shifting from manual or scheduled triggers to a truly event-driven approach. This is fundamental to ensuring the capacity pauses precisely after the intended work duration, starting from the moment it is resumed. The process unfolds as follows:

1. Capacity Resumption: A user or an automated process resumes the Microsoft Fabric capacity.
2. Activity Log Detection: Azure Activity Log, which records all subscription-level events, detects this specific "resume" operation.  
3. Azure Monitor Alert Trigger: An Azure Monitor Alert is configured to specifically detect and fire upon this "Fabric Capacities - Resume" event.  
4. Logic App Invocation: The Azure Monitor alert, upon detection, automatically invokes an Azure Logic App.
5. Dynamic Delay Calculation: Inside the Logic App, a dynamic delay is calculated. This is based on the exact timestamp of the resume event (captured by the alert) and the user's predefined work duration (e.g., 2 hours).
6. API Call to Pause: After the calculated delay period has elapsed, the Logic App securely calls the Microsoft Fabric REST API to suspend the capacity.

This event-driven architecture is critical for precise cost control. The user's initial thought of a "manual trigger" for the Logic App would not fully address the problem of forgetting to pause after resuming. However, Azure Monitor Activity Log alerts provide the capability to detect specific resource operations, including the "Fabric Capacities - Resume" event. This enables the automation to be initiated precisely when the capacity is resumed, rather than relying on a fixed schedule or a separate manual action. This precision is paramount for optimizing costs, as it ties the pause logic directly to the actual start of usage, maximizing the capacity's utility while minimizing idle time. This approach transforms a reactive manual process into a proactive, automated, and highly efficient cost-saving mechanism.

Prerequisites

Before we jump in, here’s what you’ll need:

• An Azure subscription with enough permissions to create Logic Apps and manage Fabric capacity (e.g., Contributor or Fabric Admin roles).
• Basic familiarity with the Azure Portal and how Logic Apps work.

Step-by-Step Guide

Here’s how I set it up, step by step. Follow along, and you’ll have this running in no time.

Step 1: Create a Logic App

First, I needed a Logic App that could pause the Fabric capacity after a delay.

1. Head to the Azure Portal.
2. Search for Logic Apps and click Create.

1. Select Consumption as the type for this use case. (select as required)

1. Pick your Region, Resource Group, and give the Logic App a Name.
2. Hit Review + Create, then Create.

Once it’s created, it’s time to build the workflow.

1. In the Logic App Designer, choose Blank Logic App / Select Edit as per the above image
2. Search for Request and select When an HTTP request is received as the trigger.
3. Add a Delay action by clicking + New Step, searching for Delay, and setting it to 2 hours (or your preferred time).
4. Add an HTTP action by clicking + New Step, searching for HTTP, and configuring it like this:

Method: POST

URI: https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Fabric/capacities/<capacityName>/suspend?api-version=2023-11-01

Replace <subscriptionId>, <resourceGroupName>, and <capacityName> with your specific values.

Headers:

{  "Content-Type": "application/json" }

Next, I set up authentication using a Managed Identity.

1. Go to the Logic App’s Identity blade.
2. Turn System Assigned Identity to On and click Save.

1. Navigate to your Fabric Capacity resource and assign the Logic App’s identity the Contributor role (or Fabric Admin, depending on your setup).
2. Back in the HTTP action, add the Authentication parameter:
• Authentication Type: Managed Identity
• Audience: https://management.azure.com/

Save the Logic App—we’ll connect it to an alert next.

Step 2: Create an Action Group

To trigger the Logic App automatically, I created an Action Group.

1. In the Azure Portal, go to Fabric Capacity resource.
2. Click Alerts → Action Groups → Create.
3. 
4. Give it a Name, then under Actions, select Logic App.
5. Pick the Logic App you just created.
6. 

Step 3: Set Up an Alert Rule

Now, I needed an alert to fire whenever the capacity is resumed.

1. In Azure Monitor, go to Alerts → Create → Alert Rule.
2. 
3. Set the Scope to your Fabric capacity resource.
4. 
5. For the Condition, choose Activity Log, and filter for the event when the capacity is resumed (e.g., “Resume Capacity”). Check your capacity’s Activity Log to find the exact operation name.
6. 
7. Under Actions, link it to the Action Group from Step
8. 

Step 4: Testing Your Automated Cost Saver: See It in Action!

Once all the components are configured, it is crucial to test the end-to-end automation to ensure it functions as expected. This validation step helps confirm that your Fabric capacity will automatically pause after your specified work duration, leading to the desired cost savings.

1. Resume your Fabric Capacity: Begin by manually resuming your Microsoft Fabric capacity in the Azure Portal. This action serves as the initial trigger for your entire automation workflow.  
2. Monitor the Azure Activity Log: Immediately after resuming the capacity, navigate to the Azure Activity Log for your Fabric capacity resource. You should observe a "Fabric Capacities - Resume" event appearing in the log. This confirms that your Azure Monitor Alert has successfully detected the capacity resumption event.  
3. Monitor the Logic App Run:
   • Go to your Logic App resource in the Azure Portal.
   • Navigate to the "Overview" or "Run history" blade.  
   • You should see a new run initiated by the HTTP request originating from the Azure Monitor Action Group.
   • Click on the latest run to drill into its detailed execution steps. You will observe the "Delay until" action counting down for your specified work time.
   • After the delay period has elapsed, the "HTTP" action, responsible for calling the suspend API, should execute and complete successfully.
   • Visual Placeholder:
4. Verify Capacity Status: Once the Logic App run shows successful completion, return to your Fabric capacity in the Azure Portal. Its status should now be displayed as "Suspended". This confirms the automated pause was successful.  
5. Troubleshooting Tips (What to do if it doesn't work):

• Logic App not triggering:
  • Check the Azure Monitor Alert's "History" (found under "Alerts" in Azure Monitor) to determine if the alert itself fired. If it did not, re-verify your alert rule conditions (as configured in Phase 1) for accuracy.
  • Verify your Action Group configuration: ensure the correct Logic App is selected and, critically, that "Enable common alert schema" is set to "Yes".
• Logic App run failed:
  • Examine the specific error messages within the Logic App's run history. Common issues include:  
    • Authentication errors (e.g., 401 Unauthorized, 403 Forbidden): This typically indicates that your Logic App's Managed Identity lacks the necessary RBAC permissions on the Fabric capacity. Double-check the role assignment performed in Phase 3, Step 2.  
    • Bad Request (400): This often points to an issue with the HTTP action's URI or headers. Meticulously re-verify the Fabric REST API endpoint, subscription ID, resource group name, and capacity name for any typos or incorrect dynamic content expressions (Phase 3, Step 3).
    • Delay issues: Ensure your date/time calculations for the "Delay until" action are correct and that the output format adheres to the expected ISO 8601 UTC format.  
  • Capacity not pausing (but Logic App run succeeded):
    • Confirm that the HTTP call within the Logic App run history shows a successful status code (e.g., 200 OK or 202 Accepted). If the HTTP call was successful but the capacity did not pause, double-check the capacity name within the URI of the HTTP action. A successful HTTP call does not guarantee the target action was performed if the target ID was incorrect.

A comprehensive testing section is vital for any technical tutorial. It not only validates the proposed solution but also empowers the reader to confidently implement and troubleshoot it independently. Providing specific steps for verification (checking Azure Activity Log, Logic App run history, and the Fabric capacity status) and anticipating common errors demonstrates a deep, empathetic understanding of the user's potential challenges. This proactive guidance, coupled with clear troubleshooting steps, reinforces the practical and helpful nature of the guide.

Conclusion

Forgetting to pause a Fabric capacity doesn’t have to mean extra costs anymore. With this setup, I’ve got peace of mind knowing my capacity will pause itself after my work is done. It’s a small effort upfront for a big payoff in savings. Give it a try, and let me know how it goes—or if you’ve got any tweaks to make it even better!

Reference links:

https://learn.microsoft.com/en-us/rest/api/microsoftfabric/fabric-capacities/suspend?view=rest-micro...

Pause and resume your capacity - Microsoft Fabric | Microsoft Learn