Limits and configuration reference for Azure Logic Apps

For Consumption logic app workflows, the same setting controls the maximum number of days that a workflow can run and for keeping run history in storage.

• In multitenant Azure Logic Apps, the 90-day default limit is the same as the maximum limit. You can only decrease this value.

For example, suppose that you reduce the retention limit from 90 days to 30 days. A 60-day-old run is removed from the runs history. If you increase the retention period from 30 days to 60 days, a 20-day-old run stays in the runs history for another 40 days.

Portal

1. In the Azure portal search box, open your logic app workflow in the designer.

2. On the logic app menu, select Workflow settings.

3. Under Runtime options, from the Run history retention in days list, select Custom.

4. Drag the slider to change the number of days that you want.

5. When you're done, on the Workflow settings toolbar, select Save.

ARM template

If you use an Azure Resource Manager template, this setting appears as a property in your workflow's resource definition.

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

For Standard logic app workflows, you can decrease or increase the 90-day default limit, but you need to add the following settings and their values to your logic app resource or project:

• An app setting named Workflows.RuntimeConfiguration.RetentionInDays

• A host setting named Runtime.FlowMaintenanceJob.RetentionCooldownInterval

By default, the app setting named Workflows.RuntimeConfiguration.RetentionInDays is set to keep 90 days of data. The host setting named Runtime.FlowMaintenanceJob.RetentionCooldownInterval is set to check every 7 days for old data to delete. If you leave these default values, you might see data up to 97 days old. For example, suppose Azure Logic Apps checks on Day X and deletes data older than Day X - 90 days, and then waits for 7 days before running again. This behavior results in data that ages up to 97 days before the job runs again. However, if you set the interval to 1 day, but leave the retention days at the default value, the maximum delay to delete old data is 90+1 days.

Portal

1. Follow these steps to add the app setting named Workflows.RuntimeConfiguration.RetentionInDays, and set the value to the number days that you want to keep your workflow run history.

2. Follow these steps to add the host setting named Runtime.FlowMaintenanceJob.RetentionCooldownInterval, and set the value to the number of days as the interval between when to check for and delete run history that you don't want to keep.

Visual Studio Code

1. Follow these steps to add the app setting named Workflows.RuntimeConfiguration.RetentionInDays, and set the value to the number days that you want to keep your workflow run history.

2. Follow these steps to add the host setting named Runtime.FlowMaintenanceJob.RetentionCooldownInterval, and set the value to the number of days as the interval between when to check for and delete run history that you don't want to keep.

In single-tenant Azure Logic Apps, a Standard logic app resource uses storage and compute as the primary resources to run workflows.

Storage

Stateful workflows in single-tenant Azure Logic Apps use Azure Table Storage for persistent data storage during runtime, Azure Blob Storage for maintaining workflow run histories, and Azure Queue Storage for scheduling purposes. For example, a single storage account enables handling a substantial number of requests with rates of up to 2,000 requests per partition and 20,000 requests per second at the storage account level. While a single storage account can handle reasonably high throughput, beyond these thresholds, request rates are subject to throttling, and your workflows might experience partition level throttling or account level throttling as workflow execution rate increases. To make sure that your workflows operate smoothly, it's crucial that you understand the possible limitations and the ways that you can address them.

For more information about scaling targets and limitations for the various Azure Storage services, see the following documentation:

• Scale targets for Table Storage
• Data operation targets for Table Storage
• Scale targets for Blob Storage
• Scale targets for Queue Storage

Scale your logic app for storage limitations

The following recommendations apply to scaling Standard logic app workflows:

• Share workload across multiple workflows.

  Single-tenant Azure Logic Apps already minimizes partition-level throttling by distributing storage transactions across multiple partitions. However, to improve distribution and mitigate partition-level throttling, distribute the workload across multiple workflows, rather than rely on a single workflow.

• Share workload across multiple storage accounts.

  If your workflows require high throughput, you can significantly increase throughput by distributing the workload across multiple storage accounts, rather than rely on a single storage account. You can set up your Standard logic app resource to use up to 32 storage accounts as the limit. To determine the number of storage accounts that you need, use the general guideline of aiming for ~100,000 action executions per minute, per storage account. While this estimate works well for most scenarios, you might use a lower number of action executions if your workflow actions are compute heavy, for example, a query action that processes large data arrays. Make sure that you perform load testing and tune your solution before using in production.

  To enable using multiple storage accounts, follow these steps before you create your Standard logic app. Otherwise, if you change the settings after creation, you might experience data loss or not achieve the necessary scalability.

  1. Create the storage accounts that you want to use. Save the connection string for each storage account.

  2. Find and open your Standard logic app, and then edit your logic app's host settings (host.json file) to include the following extensions object, which contains the workflow and settings objects with the Runtime.ScaleUnitsCount setting:

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     The following example specifies 3 as the number of storage accounts:

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. Edit your logic app's application configuration settings (local.settings.json) to add an app setting named CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number>.ConnectionString and the corresponding storage account connection string using the following syntax where the first storage account number is 00 up to the number of storage accounts minus 1, for example:

     App setting name	Value
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     Important

     When you have sensitive information, such as connection strings that include usernames and passwords, make sure to use the most secure authentication flow available. For example, in Standard logic app workflows, secure data types, such as securestring and secureobject, aren't supported. Microsoft recommends that you authenticate access to Azure resources with a managed identity when possible, and assign a role that has the least privilege necessary.

     If this capability is unavailable, make sure to secure connection strings through other measures, such as Azure Key Vault, which you can use with app settings. You can then directly reference secure strings, such as connection strings and keys. Similar to ARM templates, where you can define environment variables at deployment time, you can define app settings within your logic app workflow definition. You can then capture dynamically generated infrastructure values, such as connection endpoints, storage strings, and more. For more information, see Application types for the Microsoft identity platform.

  4. In your logic app's application configuration settings, update the AzureWebJobsStorage setting value with the same connection string that's in the CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString setting.

Compute

A Standard logic app runs by using one of the available compute plans, which provide different levels of virtual CPU and memory, or by using an App Service Environment v3, which provides more compute options.

Single-tenant Azure Logic Apps dynamically scales to effectively handle increasing loads. Your logic app uses the following primary factors to determine whether to scale.

• Trigger

  To determine scaling requirements, the scaler analyzes the trigger that starts each workflow in your logic app. For example, for a workflow with a Service Bus trigger, if the queue length continuously grows, the scaler takes action to add worker instances, which enable processing more messages. Likewise, for a workflow with a Request trigger, if the request latency experiences an upward trend, the scaler increases the number of worker instances to distribute the request load more efficiently. For more information about worker instances, see Azure Logic Apps (Standard) - Runtime Deep Dive.

• Workflow job execution delay

  At runtime, workflow actions are divided into individual jobs that are queued for execution. Job dispatchers regularly poll the job queue to retrieve and execute these jobs. However, if compute capacity is insufficient to pick up these jobs, they stay in the queue for a longer time, resulting in increased execution delays. The scaler monitors this situation and make scaling decisions to keep the execution delays under control. For more information about how the runtime schedules and runs jobs, see Azure Logic Apps (Standard) - Runtime Deep Dive.

  The scaler also considers the minimum and maximum worker instance counter configuration to determine whether to make scaling decisions, such as adding, removing, or maintaining the current number of worker instances. Typically, the scaler makes these decisions at intervals of approximately 15-30 seconds. So, consider this ramp-up time and its impact on your logic app's scaling speed to effectively handle peak loads. For example, if your workload requires scaling your logic app from just 1 worker instance to 100 worker instances, the ramp-up alone might take 25-50 minutes. Single-tenant Azure Logic Apps scaling shares the same Azure Functions scaling infrastructure.

Configure your logic app compute for faster scaling

• Share workload across multiple logic apps.

  Each logic app can scale independently, so distributing your workload across more than one logic app can significantly accelerate the scaling speed. For example, two logic apps can scale to twice the number of worker instances in the same timeframe as a single logic app. By splitting your workload across multiple apps, you can effectively multiply the scalability and achieve faster scaling results.

• Use prewarmed instances.

  If your scenario requires quicker ramp-up time, consider using prewarmed instances. If your peak load times are deterministic, you can use an automation task to adjust these prewarm instances on a schedule.

Multitenant Azure Logic Apps has a default limit on the number of actions that run every 5 minutes. To raise the default value to the maximum value, you can enable high throughput mode, which is in preview. Or, distribute the workload across multiple logic apps and workflows, rather than rely on a single logic app and workflow.

Enable high throughput in the portal

1. In the Azure portal, on your logic app's menu, under Settings, select Workflow settings.

2. Under Runtime options > High throughput, change the setting to On.

   

Enable high throughput in a Resource Manager template

To enable this setting in an ARM template for deploying your logic app, in the properties object for your logic app's resource definition, add the runtimeConfiguration object with the operationOptions property set to OptimizedForHighThroughput:

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

For more information about your logic app resource definition, review Overview: Automate deployment for Azure Logic Apps by using Azure Resource Manager templates.