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.

• In an ISE, you can decrease or increase the 90-day default limit.

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.

Single-tenant Azure Logic Apps uses storage and compute as the primary resources to run your Standard logic app workflows.

Storage

Stateful workflows use Azure Table storage and Azure Blob storage for persistenting data storage during runtime and for maintaining run histories. These workflows also use Azure Queues for scheduling. A single storage account enables a substantial number of requests with rates of up to 2K per partition and 20K requests per second at the account level. Beyond these thresholds, request rates are subject to throttling. For storage scalability limits, see Targets for data operations.

Although a single storage account can handle reasonably high throughput, as the workflow execution rate increases, you might encounter partition level throttling or account level throttling. To ensure smooth operations, make sure that you understand the possible limitations and ways that you can address them.

Share workload across multiple workflows

Single-tenant Azure Logic Apps 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 a single workflow.

Share workload across multiple storage accounts

If your logic app's workflows require high throughput, use multiple storage accounts, rather than a single account. You can significantly increase throughput by distributing your logic app's workload across multiple storage accounts with 32 as the limit. To determine the number of storage accounts that you need, use the general guideline for ~100,000 action executions per minute, per storage account. While this estimate works well for most scenarios, the number of actions might be lower 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>

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.