Edit host and app settings for Standard logic apps in single-tenant Azure Logic Apps

Applies to: Azure Logic Apps (Standard)

In single-tenant Azure Logic Apps, the app settings for a Standard logic app specify the global configuration options that affect all the workflows in that logic app. However, these settings apply only when these workflows run in your local development environment. Locally running workflows can access these app settings as local environment variables, which are used by local development tools for values that can often change between environments. For example, these values can contain connection strings. When you deploy to Azure, app settings are ignored and aren't included with your deployment.

Your logic app also has host settings, which specify the runtime configuration settings and values that apply to all the workflows in that logic app, for example, default values for throughput, capacity, data size, and so on, whether they run locally or in Azure.

App settings, parameters, and deployment

In multitenant Azure Logic Apps, deployment depends on Azure Resource Manager templates (ARM templates), which combine and handle resource provisioning for both logic apps and infrastructure. This design poses a challenge when you have to maintain environment variables for logic apps across various dev, test, and production environments. Everything in an ARM template is defined at deployment. If you need to change just a single variable, you have to redeploy everything.

In single-tenant Azure Logic Apps, deployment becomes easier because you can separate resource provisioning between apps and infrastructure. You can use parameters to abstract values that might change between environments. By defining parameters to use in your workflows, you can first focus on designing your workflows, and then insert your environment-specific variables later. You can call and reference your environment variables at runtime by using app settings and parameters. That way, you don't have to redeploy as often.

App settings integrate with Azure Key Vault. You can directly reference secure strings, such as connection strings and keys. Similar to Azure Resource Manager templates (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. However, app settings have size limitations and can't be referenced from certain areas in Azure Logic Apps.

Note

If you use Key Vault, make sure that you store only secrets, such as passwords, credentials, and certificates. In a logic app workflow, don't use Key Vault to store non-secret values, such as URL paths, that the workflow designer needs to make calls. The designer can't dereference an app setting that references a Key Vault resource type, which results in an error and a failed call. For non-secret values, store them directly in app settings.

For more information about setting up your logic apps for deployment, see the following documentation:

Visual Studio Code project structure

In Visual Studio Code, your logic app project has either of the following types:

  • Extension bundle-based (Node.js), which is the default type
  • NuGet package-based (.NET), which you can convert from the default type

Based on these types, your project includes slightly different folders and files. A NuGet-based project includes a .bin folder that contains packages and other library files. A bundle-based project doesn't include the .bin folder and other files. Some scenarios require a NuGet-based project for your app to run, for example, when you want to develop and run custom built-in operations. For more information about converting your project to use NuGet, review Enable built-connector authoring.

For the default bundle-based project, your project has a folder and file structure that is similar to the following example:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

At your project's root level, you can find the following files and folders with other items:

Name Folder or file Description
.vscode Folder Contains Visual Studio Code-related settings files, such as extensions.json, launch.json, settings.json, and tasks.json files.
Artifacts Folder Contains integration account artifacts that you define and use in workflows that support business-to-business (B2B) scenarios. For example, the example structure includes maps and schemas for XML transform and validation operations.
<WorkflowName> Folder For each workflow, the <WorkflowName> folder includes a workflow.json file, which contains that workflow's underlying JSON definition.
workflow-designtime Folder Contains development environment-related settings files.
.funcignore File Contains information related to your installed Azure Functions Core Tools.
connections.json File Contains the metadata, endpoints, and keys for any managed connections and Azure functions that your workflows use.

Important: To use different connections and functions for each environment, make sure that you parameterize this connections.json file and update the endpoints.
host.json File Contains runtime-specific configuration settings and values, for example, the default limits for the single-tenant Azure Logic Apps platform, logic apps, workflows, triggers, and actions. At your logic app project's root level, the host.json metadata file contains the configuration settings and default values that all workflows in the same logic app use while running, whether locally or in Azure.

Note: When you create your logic app, Visual Studio Code creates a backup host.snapshot.*.json file in your storage container. If you delete your logic app, this backup file isn't deleted. If you create another logic app with the same name, another snapshot file is created. You can have only up to 10 snapshots for the same logic app. If you exceed this limit, you get the following error:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

To resolve this error, delete the extra snapshot files from your storage container.
local.settings.json File Contains app settings, connection strings, and other settings that your workflows use while running locally. In other words, these settings and values apply only when you run your projects in your local development environment. During deployment to Azure, the file and settings are ignored and aren't included with your deployment.

This file stores settings and values as local environment variables that are used by your local development tools as the appSettings values. You can call and reference these environment variables both at runtime and deployment time by using app settings and parameters.

Important: The local.settings.json file can contain secrets, so make sure that you also exclude this file from your project source control.

Reference for app settings - local.settings.json

In Visual Studio Code, at your logic app project's root level, the local.settings.json file contain global configuration options that affect all workflows in that logic app while running in your local development environment. When your workflows run locally, these settings are accessed as local environment variables, and their values can often change between the various environments where you run your workflows. To view and manage these settings, review Manage app settings - local.settings.json.

App settings in Azure Logic Apps work similarly to app settings in Azure Functions or Azure Web Apps. If you've used these other services before, you might already be familiar with app settings. For more information, review App settings reference for Azure Functions and Work with Azure Functions Core Tools - Local settings file.

For your workflow to run properly, some app settings are required.

Setting Required Value Description
APP_KIND Yes workflowApp Required to set the app type for the Standard logic app resource.
AzureWebJobsStorage Yes None Required to set the connection string for an Azure storage account. For more information, see AzureWebJobsStorage.
FUNCTINONS_EXTENSION_VERSION Yes ~4 Required to set the Azure Functions version. For more information, see FUNCTIONS_EXTENSION_VERSION.
FUNCTIONS_WORKER_RUNTIME Yes dotnet Required to set the language worker runtime for your logic app resource and workflows.

Note: This setting's value was previously set to node, but now the required value is dotnet for all new and existing deployed Standard logic apps. This change shouldn't affect your workflow's runtime, so everything should work the same way as before.

For more information, see FUNCTIONS_WORKER_RUNTIME.
ServiceProviders.Sftp.FileUploadBufferTimeForTrigger No 00:00:20
(20 seconds)
Sets the buffer time to ignore files that have a last modified timestamp that's greater than the current time. This setting is useful when large file writes take a long time and avoids fetching data for a partially written file.
ServiceProviders.Sftp.OperationTimeout No 00:02:00
(2 min)
Sets the time to wait before timing out on any operation.
ServiceProviders.Sftp.ServerAliveInterval No 00:30:00
(30 min)
Sends a "keep alive" message to keep the SSH connection active if no data exchange with the server happens during the specified period.
ServiceProviders.Sftp.SftpConnectionPoolSize No 2 connections Sets the number of connections that each processor can cache. The total number of connections that you can cache is ProcessorCount multiplied by the setting value.
ServiceProviders.MaximumAllowedTriggerStateSizeInKB No 10 KB, which is ~1,000 files Sets the trigger state entity size in kilobytes, which is proportional to the number of files in the monitored folder and is used to detect files. If the number of files exceeds 1,000, increase this value.
ServiceProviders.Sql.QueryTimeout No 00:02:00
(2 min)
Sets the request timeout value for SQL service provider operations.
WEBSITE_CONTENTSHARE Yes Dynamic Required to set the name for the file share that Azure Functions uses to store function app code and configuration files and is used with WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. The default is a unique string generated by the runtime. For more information, see WEBSITE_CONTENTSHARE.
WEBSITE_LOAD_ROOT_CERTIFICATES No None Sets the thumbprints for the root certificates to be trusted.
Workflows.Connection.AuthenticationAudience No None Sets the audience for authenticating a managed (Azure-hosted) connection.
Workflows.CustomHostName No None Sets the host name to use for workflow and input-output URLs, for example, "logic.contoso.com". For information to configure a custom DNS name, see Map an existing custom DNS name to Azure App Service and Secure a custom DNS name with a TLS/SSL binding in Azure App Service.
Workflows.<workflowName>.FlowState No None Sets the state for <workflowName>.
Workflows.<workflowName>.RuntimeConfiguration.RetentionInDays No None Sets the amount of time in days to keep the run history for <workflowName>.
Workflows.RuntimeConfiguration.RetentionInDays No 90 days Sets the amount of time in days to keep workflow run history after a run starts.
Workflows.WebhookRedirectHostUri No None Sets the host name to use for webhook callback URLs.

Manage app settings - local.settings.json

To add, update, or delete app settings, select and review the following sections for Azure portal, Visual Studio Code, Azure CLI, or ARM (Bicep) template. For app settings specific to logic apps, review the reference guide for available app settings - local.settings.json.

View app settings in the portal
  1. In the Azure portal search box, find and open your logic app.

  2. On your logic app menu, under Settings, select Environment variables.

  3. On the Environment variables page, on the App settings tab, review the app settings for your logic app.

    For more information about these settings, review the reference guide for available app settings - local.settings.json.

  4. To view all values, select Show Values. Or, to view a single value, in the Value column, next to the value, select the "eye".

Add an app setting in the portal
  1. On the App settings tab, at the bottom of the list, in the Name column, enter the key or name for your new setting.

  2. For Value, enter the value for your new setting.

  3. When you're ready to create your new key-value pair, select Apply.

    Screenshot shows Azure portal with app settings page and values for a Standard logic app resource.

Reference for host settings - host.json

In Visual Studio Code, at your logic app project's root level, the host.json metadata file contains the runtime settings and default values that apply to all workflows in a logic app resource whether running locally or in Azure. To view and manage these settings, review Manage host settings - host.json. You can also find related limits information in the Limits and configuration for Azure Logic Apps documentation.

Job orchestration throughput

These settings affect the throughput and capacity for single-tenant Azure Logic Apps to run workflow operations.

Setting Default value Description
Jobs.BackgroundJobs.DispatchingWorkersPulseInterval 00:00:01
(1 sec)
Sets the interval for job dispatchers to poll the job queue when the previous poll returns no jobs. Job dispatchers poll the queue immediately when the previous poll returns a job.
Jobs.BackgroundJobs.NumPartitionsInJobDefinitionsTable 4 job partitions Sets the number of job partitions in the job definition table. This value controls how much execution throughput is affected by partition storage limits.
Jobs.BackgroundJobs.NumPartitionsInJobTriggersQueue 1 job queue Sets the number of job queues monitored by job dispatchers for jobs to process. This value also affects the number of storage partitions where job queues exist.
Jobs.BackgroundJobs.NumWorkersPerProcessorCount 192 dispatcher worker instances Sets the number of dispatcher worker instances or job dispatchers to have per processor core. This value affects the number of workflow runs per core.
Jobs.BackgroundJobs.StatelessNumWorkersPerProcessorCount 192 dispatcher worker instances Sets the number of dispatcher worker instances or job dispatchers to have per processor core, per stateless run. This value affects the number of concurrent workflow actions that are processed per run.

Both of the following settings are used to manually stop and immediately delete the specified workflows in Standard logic app.

Note

Use these settings with caution and only in non-production environments, such as load or performance test environments, as you can't undo or recover from these operations.

Setting Default value Description
Jobs.CleanupJobPartitionPrefixes None Immediately deletes all the run jobs for the specified workflows.
Jobs.SuspendedJobPartitionPartitionPrefixes None Stops the run jobs for the specified workflows.

The following example shows the syntax for these settings where each workflow ID is followed by a colon (:) and separated by a semicolon (;):

"Jobs.CleanupJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2:",
"Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"

Recurrence-based triggers

Setting Default value Description
Microsoft.Azure.Workflows.ServiceProviders.MaximumAllowedTriggerStateSizeInKB 1 KB Sets the trigger state's maximum allowed size for recurrence-based triggers such as the built-in SFTP trigger. The trigger state persists data across multiple service provider recurrence-based triggers.

Important: Based on your storage size, avoid setting this value too high, which can adversely affect storage and performance.

Trigger concurrency

The following settings work only for workflows that start with a recurrence-based trigger for built-in, service provider-based connectors. For a workflow that starts with a function-based trigger, you might try to set up batching where supported. However, batching isn't always the correct solution. For example, with Azure Service Bus triggers, a batch might hold onto messages beyond the lock duration. As a result, any action, such as complete or abandon, fails on such messages.

Setting Default value Description
Runtime.Trigger.MaximumRunConcurrency 100 runs Sets the maximum number of concurrent runs that a trigger can start. This value appears in the trigger's concurrency definition.
Runtime.Trigger.MaximumWaitingRuns 200 runs Sets the maximum number of runs that can wait after concurrent runs meet the maximum. This value appears in the trigger's concurrency definition. For more information, see Change waiting runs limit.

Run duration and history retention

Setting Default value Description
Runtime.Backend.FlowRunTimeout 90.00:00:00
(90 days)
Sets the amount of time a workflow can continue running before forcing a timeout. The minimum value for this setting is 7 days.

Important: Make sure this value is less than or equal to the value for the app setting named Workflows.RuntimeConfiguration.RetentionInDays. Otherwise, run histories can get deleted before the associated jobs are complete.
Runtime.FlowMaintenanceJob.RetentionCooldownInterval 7.00:00:00
(7 days)
Sets the amount of time in days as the interval between when to check for and delete run history that you no longer want to keep.

Run actions

Setting Default value Description
Runtime.FlowRunRetryableActionJobCallback.ActionJobExecutionTimeout 00:10:00
(10 minutes)
Sets the amount of time for a workflow action job to run before timing out and retrying.

Inputs and outputs

Setting Default value Description
Microsoft.Azure.Workflows.TemplateLimits.InputParametersLimit 50 Change the default limit on cross-environment workflow parameters up to 500 for Standard logic apps created by exporting Consumption logic apps.
Runtime.ContentLink.MaximumContentSizeInBytes 104857600 bytes Sets the maximum size in bytes that an input or output can have in a single trigger or action.
Runtime.FlowRunActionJob.MaximumActionResultSize 209715200 bytes Sets the maximum size in bytes that the combined inputs and outputs can have in a single action.

Pagination

Setting Default value Description
Runtime.FlowRunRetryableActionJobCallback.MaximumPageCount 1000 pages When pagination is supported and enabled on an operation, sets the maximum number of pages to return or process at runtime.

Chunking

Setting Default value Description
Runtime.FlowRunRetryableActionJobCallback.MaximumContentLengthInBytesForPartialContent 1073741824 bytes When chunking is supported and enabled on an operation, sets the maximum size in bytes for downloaded or uploaded content.
Runtime.FlowRunRetryableActionJobCallback.MaxChunkSizeInBytes 52428800 bytes When chunking is supported and enabled on an operation, sets the maximum size in bytes for each content chunk.
Runtime.FlowRunRetryableActionJobCallback.MaximumRequestCountForPartialContent 1000 requests When chunking is supported and enabled on an operation, sets the maximum number of requests that an action execution can make to download content.

Store content inline or use blobs

Setting Default value Description
Runtime.FlowRunEngine.ForeachMaximumItemsForContentInlining 20 items When a For each loop is running, each item's value is stored either inline with other metadata in table storage or separately in blob storage. Sets the number of items to store inline with other metadata.
Runtime.FlowRunRetryableActionJobCallback.MaximumPagesForContentInlining 20 pages Sets the maximum number of pages to store as inline content in table storage before storing in blob storage.
Runtime.FlowTriggerSplitOnJob.MaximumItemsForContentInlining 40 items When the SplitOn setting debatches array items into multiple workflow instances, each item's value is stored either inline with other metadata in table storage or separately in blob storage. Sets the number of items to store inline.
Runtime.ScaleUnit.MaximumCharactersForContentInlining 8192 characters Sets the maximum number of operation input and output characters to store inline in table storage before storing in blob storage.

For each loops

Setting Default value Description
Runtime.Backend.FlowDefaultForeachItemsLimit 100000 array items For a stateful workflow, sets the maximum number of array items to process in a For each loop.
Runtime.Backend.FlowDefaultSplitOnItemsLimit 100000 array items Sets the maximum number of array items to debatch or split into multiple workflow instances based on the SplitOn setting.
Runtime.Backend.ForeachDefaultDegreeOfParallelism 20 iterations Sets the default number of concurrent iterations, or degree of parallelism, in a For each loop. To run sequentially, set the value to 1.
Runtime.Backend.Stateless.FlowDefaultForeachItemsLimit 100 items For a stateless workflow, sets the maximum number of array items to process in a For each loop.

Until loops

Setting Default value Description
Runtime.Backend.MaximumUntilLimitCount 5000 iterations For a stateful workflow, sets the maximum number possible for the Count property in an Until action.
Runtime.Backend.Stateless.FlowRunTimeout 00:05:00
(5 min)
Sets the maximum wait time for an Until loop in a stateless workflow.
Runtime.Backend.Stateless.MaximumUntilLimitCount 100 iterations For a stateless workflow, sets the maximum number possible for the Count property in an Until action.

Variables

Setting Default value Description
Runtime.Backend.DefaultAppendArrayItemsLimit 100000 array items Sets the maximum number of items in a variable with the Array type.
Runtime.Backend.VariableOperation.MaximumStatelessVariableSize Stateless workflow: 1024 characters Sets the maximum size in characters for the content that a variable can store when used in a stateless workflow.
Runtime.Backend.VariableOperation.MaximumVariableSize Stateful workflow: 104857600 characters Sets the maximum size in characters for the content that a variable can store when used in a stateful workflow.

Built-in HTTP operations

Setting Default value Description
Runtime.Backend.HttpOperation.DefaultRetryCount 4 retries Sets the default retry count for HTTP triggers and actions.
Runtime.Backend.HttpOperation.DefaultRetryInterval 00:00:07
(7 sec)
Sets the default retry interval for HTTP triggers and actions.
Runtime.Backend.HttpOperation.DefaultRetryMaximumInterval 01:00:00
(1 hour)
Sets the maximum retry interval for HTTP triggers and actions.
Runtime.Backend.HttpOperation.DefaultRetryMinimumInterval 00:00:05
(5 sec)
Sets the minimum retry interval for HTTP triggers and actions.
Runtime.Backend.HttpOperation.MaxContentSize 104857600 bytes Sets the maximum request size in bytes for HTTP actions only, not triggers. For more information, see Limitations.
Runtime.Backend.HttpOperation.RequestTimeout 00:03:45
(3 min and 45 sec)

Note: The default value is also the maximum value.
Sets the request timeout value for HTTP triggers and actions.

Built-in HTTP Webhook operations

Setting Default value Description
Runtime.Backend.HttpWebhookOperation.DefaultRetryCount 4 retries Sets the default retry count for HTTP webhook triggers and actions.
Runtime.Backend.HttpWebhookOperation.DefaultRetryInterval 00:00:07
(7 sec)
Sets the default retry interval for HTTP webhook triggers and actions.
Runtime.Backend.HttpWebhookOperation.DefaultRetryMaximumInterval 01:00:00
(1 hour)
Sets the maximum retry interval for HTTP webhook triggers and actions.
Runtime.Backend.HttpWebhookOperation.DefaultRetryMinimumInterval 00:00:05
(5 sec)
Sets the minimum retry interval for HTTP webhook triggers and actions.
Runtime.Backend.HttpWebhookOperation.DefaultWakeUpInterval 01:00:00
(1 hour)
Sets the default wake-up interval for HTTP webhook trigger and action jobs.
Runtime.Backend.HttpWebhookOperation.MaxContentSize 104857600 bytes Sets the maximum request size in bytes for HTTP webhook actions only, not triggers. For more information, see Limitations.
Runtime.Backend.HttpWebhookOperation.RequestTimeout 00:02:00
(2 min)
Sets the request timeout value for HTTP webhook triggers and actions.

Built-in Azure Storage operations

Blob storage

Setting Default value Description
Microsoft.Azure.Workflows.ContentStorage.RequestOptionsThreadCount None Sets the thread count for blob upload and download operations. You can use this setting to force the Azure Logic Apps runtime to use multiple threads when uploading and downloading content from action inputs and outputs.
Runtime.ContentStorage.RequestOptionsDeltaBackoff 00:00:02
(2 sec)
Sets the backoff interval between retries sent to blob storage.
Runtime.ContentStorage.RequestOptionsMaximumAttempts 4 retries Sets the maximum number of retries sent to table and queue storage.
Runtime.ContentStorage.RequestOptionsMaximumExecutionTime 00:02:00
(2 min)
Sets the operation timeout value, including retries, for blob requests from the Azure Logic Apps runtime.
Runtime.ContentStorage.RequestOptionsServerTimeout 00:00:30
(30 sec)
Sets the timeout value for blob requests from the Azure Logic Apps runtime.

Table and queue storage

Setting Default value Description
Runtime.DataStorage.RequestOptionsDeltaBackoff 00:00:02
(2 sec)
Sets the backoff interval between retries sent to table and queue storage.
Runtime.DataStorage.RequestOptionsMaximumAttempts 4 retries Sets the maximum number of retries sent to table and queue storage.
Runtime.DataStorage.RequestOptionsMaximumExecutionTime 00:00:45
(45 sec)
Sets the operation timeout value, including retries, for table and queue storage requests from the Azure Logic Apps runtime.
Runtime.DataStorage.RequestOptionsServerTimeout 00:00:16
(16 sec)
Sets the timeout value for table and queue storage requests from the Azure Logic Apps runtime.

File share

Setting Default value Description
ServiceProviders.AzureFile.MaxFileSizeInBytes 150000000 bytes Sets the maximum file size in bytes for an Azure file share.

Built-in Azure Functions operations

Setting Default value Description
Runtime.Backend.FunctionOperation.RequestTimeout 00:03:45
(3 min and 45 sec)
Sets the request timeout value for Azure Functions actions.
Runtime.Backend.FunctionOperation.MaxContentSize 104857600 bytes Sets the maximum request size in bytes for Azure Functions actions. For more information, see Limitations.
Runtime.Backend.FunctionOperation.DefaultRetryCount 4 retries Sets the default retry count for Azure Functions actions.
Runtime.Backend.FunctionOperation.DefaultRetryInterval 00:00:07
(7 sec)
Sets the default retry interval for Azure Functions actions.
Runtime.Backend.FunctionOperation.DefaultRetryMaximumInterval 01:00:00
(1 hour)
Sets the maximum retry interval for Azure Functions actions.
Runtime.Backend.FunctionOperation.DefaultRetryMinimumInterval 00:00:05
(5 sec)
Sets the minimum retry interval for Azure Functions actions.

Built-in Azure Service Bus operations

Setting Default value Description
ServiceProviders.ServiceBus.MessageSenderOperationTimeout 00:01:00
(1 min)
Sets the timeout for sending messages with the built-in Service Bus operation.
Runtime.ServiceProviders.ServiceBus.MessageSenderPoolSizePerProcessorCount 64 message senders Sets the number of Azure Service Bus message senders per processor core to use in the message sender pool.

Built-in SFTP operations

Setting Default value Description
Runtime.ServiceProviders.Sftp.MaxFileSizeInBytes 2147483648 bytes Sets the maximum file size in bytes for the Get file content (V2) action.
Runtime.ServiceProviders.Sftp.MaximumFileSizeToReadInBytes 209715200 bytes Sets the maximum file size in bytes for the Get file content action. Make sure this value doesn't exceed the referenceable memory size because this action reads file content in memory.

Managed connector operations

Setting Default value Description
Runtime.Backend.ApiConnectionOperation.RequestTimeout 00:02:00
(2 min)
Sets the request timeout value for managed API connector triggers and actions.
Runtime.Backend.ApiConnectionOperation.MaxContentSize 104857600 bytes Sets the maximum request size in bytes for managed API connector triggers and actions. For more information, see Limitations.
Runtime.Backend.ApiConnectionOperation.DefaultRetryCount 4 retries Sets the default retry count for managed API connector triggers and actions.
Runtime.Backend.ApiConnectionOperation.DefaultRetryInterval 00:00:07
(7 sec)
Sets the default retry interval for managed API connector triggers and actions.
Runtime.Backend.ApiWebhookOperation.DefaultRetryMaximumInterval 01:00:00
(1 day)
Sets the maximum retry interval for managed API connector webhook triggers and actions.
Runtime.Backend.ApiConnectionOperation.DefaultRetryMinimumInterval 00:00:05
(5 sec)
Sets the minimum retry interval for managed API connector triggers and actions.
Runtime.Backend.ApiWebhookOperation.DefaultWakeUpInterval 01:00:00
(1 day)
Sets the default wake-up interval for managed API connector webhook trigger and action jobs.

Retry policy for all other operations

Setting Default value Description
Runtime.ScaleMonitor.MaxPollingLatency 00:00:30
(30 sec)
Sets the maximum polling latency for runtime scaling.
Runtime.Backend.Operation.MaximumRetryCount 90 retries Sets the maximum number of retries in the retry policy definition for a workflow operation.
Runtime.Backend.Operation.MaximumRetryInterval 01:00:00:01
(1 day and 1 sec)
Sets the maximum interval in the retry policy definition for a workflow operation.
Runtime.Backend.Operation.MinimumRetryInterval 00:00:05
(5 sec)
Sets the minimum interval in the retry policy definition for a workflow operation.

Limitations

Manage host settings - host.json

You can add, update, or delete host settings, which specify the runtime configuration settings and values that apply to all the workflows in that logic app, such as default values for throughput, capacity, data size, and so on, whether they run locally or in Azure. For host settings specific to logic apps, review the reference guide for available runtime and deployment settings - host.json.

Azure portal - host.json

To review the host settings for your single-tenant based logic app in the Azure portal, follow these steps:

  1. In the Azure portal search box, find and open your logic app.

  2. On your logic app menu, under Development Tools, select Advanced Tools.

  3. On the Advanced Tools page, select Go, which opens the Kudu environment for your logic app.

  4. On the Kudu toolbar, from the Debug console menu, select CMD.

  5. In the Azure portal, stop your logic app.

    1. On your logic app menu, select Overview.

    2. On the Overview pane's toolbar, select Stop.

  6. On your logic app menu, under Development Tools, select Advanced Tools.

  7. On the Advanced Tools pane, select Go, which opens the Kudu environment for your logic app.

  8. On the Kudu toolbar, open the Debug console menu, and select CMD.

    A console window opens so that you can browse to the wwwroot folder using the command prompt. Or, you can browse the directory structure that appears above the console window.

  9. Browse along the following path to the wwwroot folder: ...\home\site\wwwroot.

  10. Above the console window, in the directory table, next to the host.json file, select Edit.

  11. After the host.json file opens, review any host settings that were previously added for your logic app.

    For more information about host settings, review the reference guide for available host settings - host.json.

To add a setting, follow these steps:

  1. Before you add or edit settings, stop your logic app in the Azure portal.

    1. On your logic app menu, select Overview.
    2. On the Overview pane's toolbar, select Stop.
  2. Return to the host.json file. Under the extensionBundle object, add the extensions object, which includes the workflow and settings objects, for example:

    {
       "version": "2.0",
       "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle",
          "version": "[1.*, 2.0.0)"
       },
       "extensions": {
          "workflow": {
             "settings": {
             }
          }
       }
    }
    
  3. In the settings object, add a flat list with the host settings that you want to use for all the workflows in your logic app, whether those workflows run locally or in Azure, for example:

    {
       "version": "2.0",
       "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle",
          "version": "[1.*, 2.0.0)"
       },
       "extensions": {
          "workflow": {
             "settings": {
                "Runtime.Trigger.MaximumWaitingRuns": "100"
             }
          }
       }
    }
    
  4. When you're done, remember to select Save.

  5. Now, restart your logic app. Return to your logic app's Overview page, and select Restart.

Visual Studio Code - host.json

To review the host settings for your logic app in Visual Studio Code, follow these steps:

  1. In your logic app project, at the root project level, find and open the host.json file.

  2. In the extensions object, under workflows and settings, review any host settings that were previously added for your logic app. Otherwise, the extensions object won't appear in the file.

    For more information about host settings, review the reference guide for available host settings - host.json.

To add a host setting, follow these steps:

  1. In the host.json file, under the extensionBundle object, add the extensions object, which includes the workflow and settings objects, for example:

    {
       "version": "2.0",
       "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle",
          "version": "[1.*, 2.0.0)"
       },
       "extensions": {
          "workflow": {
             "settings": {
             }
          }
       }
    }
    
  2. In the settings object, add a flat list with the host settings that you want to use for all the workflows in your logic app, whether those workflows run locally or in Azure, for example:

    {
       "version": "2.0",
       "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle",
          "version": "[1.*, 2.0.0)"
       },
       "extensions": {
          "workflow": {
             "settings": {
                "Runtime.Trigger.MaximumWaitingRuns": "100"
             }
          }
       }
    }
    

Next steps