Logic App Standard running very slow, memory is high

Question

Logic App Standard running very slow, memory is high

JoelP 386

We started experiencing issues with our Logic App Standard workflows since last night. The workflows had been running normally, but several workflows suddenly became stuck in the "Running" state.

Restarting the Logic App temporarily resolves the issue, and the workflows run normally for a short period, but after several minutes to an hour, the triggers stop firing again.

We upgraded the plan to WS2, but the same symptoms persist. We have also adjusted concurrency settings, however the issue still continues.

Current symptoms include:

High memory usage
Recurrence triggers not firing
Workflows stuck in "Running" state

Restarting the Logic App restores functionality temporarily, but the issue reoccurs after some time.

It is important to note that there were no changes made to any of the Logic App workflows prior to this issue occurring.

Additionally, I noticed that the workflow extension bundle appears to have been upgraded around the same time the issue started occurring. Could someone please advise whether this could be related and how we can resolve the issue?

User's image

JoelP 386 Reputation points

2026-05-20T12:43:16.2833333+00:00

Forgout to mention, location of logic app service is hosted in australia east
Pravallika KV 15,465 Reputation points Microsoft External Staff Moderator

2026-05-20T13:41:24.1833333+00:00
Hi @JoelP ,

It sounds like your Logic App Standard in Australia East started choking on memory and scaling right around the time the workflow extension bundle bumped versions. The portal logs you shared show two big red flags:

“Logic app backend restarted due to high memory pressure” - the app pool is recycling.

“Scaling reached maximum burst limit” - you’re pinned at 1 worker and can’t scale out further.

Here are a few things to try:

Scale-out and SKU

Bump your plan from WS2 to WS3 (or higher) so each worker has more CPU/memory.

In the Scale-out blade, raise your Maximum Elastic Worker Count and consider setting a nonzero Minimum Worker Count (pre-warmed instances) so you never drop to zero.

Pin or roll back your extension bundle

In host.json, explicitly lock to the last known good bundle (e.g. "Microsoft.Azure.Functions.ExtensionBundle.Workflows": "[1.161.0,1.162.0)"). That will revert you off the newly deployed 1.165.50 until we confirm stability.

Check storage-trigger throttling

Recurrence triggers and stateful workflows use Queue/Table storage under the covers. If you see 429s in your run history, consider sharding across multiple storage accounts by configuring Runtime.ScaleUnitsCount in host.json and supplying multiple CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CUxx.ConnectionString app settings.

Understand elevated memory

The .NET Server GC used by Logic Apps Standard tends to hold on to memory segments; high “in-use” memory isn’t necessarily a leak. But repeated cold-starts and pool recycles do point back to scale constraints.

Monitor and alert

Enable diagnostics on your App Service Plan to track CPU/memory/worker-count trends. Use “Monitor run status and trigger history” to catch throttling or dispatch-queue delays early.

1 answer

Your answer

JoelP 386 Reputation points

2026-05-20T12:43:16.2833333+00:00

Forgout to mention, location of logic app service is hosted in australia east
Pravallika KV 15,465 Reputation points Microsoft External Staff Moderator

2026-05-20T13:41:24.1833333+00:00

Hi @JoelP ,

It sounds like your Logic App Standard in Australia East started choking on memory and scaling right around the time the workflow extension bundle bumped versions. The portal logs you shared show two big red flags:

“Logic app backend restarted due to high memory pressure” - the app pool is recycling.

“Scaling reached maximum burst limit” - you’re pinned at 1 worker and can’t scale out further.

Here are a few things to try:

Scale-out and SKU

Bump your plan from WS2 to WS3 (or higher) so each worker has more CPU/memory.

In the Scale-out blade, raise your Maximum Elastic Worker Count and consider setting a nonzero Minimum Worker Count (pre-warmed instances) so you never drop to zero.

Pin or roll back your extension bundle

In host.json, explicitly lock to the last known good bundle (e.g. "Microsoft.Azure.Functions.ExtensionBundle.Workflows": "[1.161.0,1.162.0)"). That will revert you off the newly deployed 1.165.50 until we confirm stability.

Check storage-trigger throttling

Recurrence triggers and stateful workflows use Queue/Table storage under the covers. If you see 429s in your run history, consider sharding across multiple storage accounts by configuring Runtime.ScaleUnitsCount in host.json and supplying multiple CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CUxx.ConnectionString app settings.

Understand elevated memory

The .NET Server GC used by Logic Apps Standard tends to hold on to memory segments; high “in-use” memory isn’t necessarily a leak. But repeated cold-starts and pool recycles do point back to scale constraints.

Monitor and alert

Enable diagnostics on your App Service Plan to track CPU/memory/worker-count trends. Use “Monitor run status and trigger history” to catch throttling or dispatch-queue delays early.

Answer 1

JoelP 386

I am trying the Scott's solution here... will feedback if it fixes the issue.https://learn.microsoft.com/en-us/answers/questions/5895298/timeouts-and-excessive-execution-times-on-workflow

JoelP 386 Reputation points

2026-05-21T01:48:29.8766667+00:00

Hi, @Pravallika KV

The above solution from Scott worked for us but got an email from Azure. How do I let them know not to purge the specific version in our logip app service?

Share via

Logic App Standard running very slow, memory is high

1 answer

Your answer