Timeouts and excessive execution times on workflows

Scott Henderson 35 Reputation points

We have more than 20 of our logic apps experiencing issues with very long execution times on workflows that normally run in seconds across mulitple ASP's and Logic Apps resources in the Australia-East region. Restarting the logic app allows some runs to run or finish then they just start "hanging" again.

We cannot see any issues in the service health for Azure.

Is anyone else experiencing any issues? We can see this first started happening late yesterday evening.

  1. Siddhesh Desai 7,480 Reputation points • Microsoft External Staff • Moderator

    Hi

    Thank you for reaching out to Microsoft Q&A

    there's an active incident affecting the Logic app in Australia region. I'll keep you updated on the incident and let you know once its resolved.

    As a workaround, Try below steps:

    Check dependent services (Storage / Connectors / Networking) Logic Apps, especially Standard, rely heavily on the associated Storage Account and external connectors. Validate that there are no latency spikes, throttling, or connectivity issues with storage, SQL, Service Bus, or any external APIs being called. Issues in dependencies can cause workflows to appear “stuck” or delayed.

    Restart as a temporary mitigation As observed, restarting the Logic App or App Service Plan may temporarily resolve the issue by reallocating workers and resetting connections. However, since this is not a permanent fix, the issue may reoccur once the workload stabilizes back on the same infrastructure.

    Apply temporary workload mitigation strategies If the impact is critical, consider reducing concurrency, breaking large workflows into smaller asynchronous patterns, or scaling up the App Service Plan (for Standard Logic Apps) to reduce immediate pressure until the platform issue is resolved.

  2. Scott Henderson 35 Reputation points

    thanks @Siddhesh Desai , you mention "there's an active incident affecting the Logic app in Australia region" What is this incident, do you have a link to the details or service status page for it? we cannot see anything in our region to explain this so far..

  3. Siddhesh Desai 7,480 Reputation points • Microsoft External Staff • Moderator

    Hi,

    There are active incidents affecting App services in different regions, and there was one incident last week which affected the Network connectivity of Azure services in Australia East region.

Sign in to comment

7 answers

  1. Joakim Nylund 10 Reputation points

    Same issue for us with the app service plans, west europe. Why has there been no communication from Microsoft?

    1. Joakim Nylund 10 Reputation points

      @Siddhesh Desai Is there any update from Microsoft regarding the resolution of the performance issues?

    2. Joakim Nylund 10 Reputation points

      Response from Microsoft:

      What went wrong, and why?

      After investigating, we identified that the issue stemmed from a recent deployment. This deployment included a change which introduced a memory-based load balancing capability that allows apps to scale appropriately when operating at high memory. The change limits crashes from role instances operating under high memory pressure. For some customers, particularly with insufficient scaling settings, this led to a reduced job processing rate, which manifested as gaps or delays in workflow execution. Customers can validate if the mitigation workstream was applied by checking if their app version is updated to 1.165.52. If version displays otherwise, we recommend restarting the application.

      How did we respond?

      02:44 UTC on 19 May 2026 – Customer impact began.

      15:41 UTC on 19 May 2026 – We detected the issue through a customer report which indicated the increased latencies for job execution in the service and started the investigation.

      16:35 UTC on 20 May 2026 – We escalated the investigation as a possible regression affecting multiple customers.

      19:16 UTC on 20 May 2026 – We identified that a recent deployment applied to the service inadvertently slowed down the job processing rate, resulting in slow workflow execution.

      12:35 UTC on 21 May 2026 – We decided to hotfix the problematic behavior.

      15:24 UTC on 21 May 2026 – We applied manual configuration to the affected regions which consisted of a hotfix that targets the problematic behavior. 

      00:00 UTC on 22 May 2026 – Further monitoring completed and full-service restoration has been confirmed by telemetry.

    3. Siddhesh Desai 7,480 Reputation points • Microsoft External Staff • Moderator

      Hi @Joakim Nylund

      The issue seems to be resolved now,

      Did you try Scott Henderson's suggestion of Changing the value of each logic apps environment environment variable named AzureFunctionsJobHost_extensionBundle_Version to [1.161.25, 1.161.25] was the solve for us.

    Sign in to comment
  2. Scott Henderson 35 Reputation points

    The cause of this issue is a microsoft update to the Workflow extension Bundle, version 1.165.50.0 is the version with the issue. 👁 image (5)

    Changing the value of each logic apps environment environment variable named AzureFunctionsJobHost_extensionBundle_Version to [1.161.25, 1.161.25] was the solve for us. Please note that this hardwires the Logic App to this version, so is a temp fix only until they can release a verion that works.

    The normal value for this environment variable is [1.*, 2.0.0), which means it will allow any version from 1.x up to (but not including) 2.0.0, so allows for updates in the code to be seamless to the Logic App. Once the issue with this code has been rectified we will be reverting back to this value to ensure we don't end up with a version that is no longer available over time.

    We are currently waiting on Microsoft to adivse us on the root cause of the issues after the change and to release a new version with the issues corrected.

    1. JoelP 411 Reputation points

      @Scott Henderson thanks mate... was up all all night figuring this out... will give it a go...

    2. JoelP 411 Reputation points

      @Scott Henderson updated to [1.161.25, 1.161.25] ... will feedback if this works for us..

    3. Simarjot Singh 0 Reputation points

      Thanks @Scott Henderson this worked for us. Any word from Microsoft regarding this?

    4. Scott Henderson 35 Reputation points

      @Simarjot Singh Nothing from Microsoft as yet, we are keeping our support case open and following up until it is fixed.

    5. BertB 0 Reputation points

      We've experienced the same issues in the Australia East and West Europe regions, but we noticed that the version of the extension bundle is now bumped from 1.165.50.0 to 1.165.52.0. After a restart the logic apps appear to be running normally again, although we are continuing to monitor for memory pressure and potential stalls.

    Sign in to comment
  3. JoelP 411 Reputation points

    Hi... We started getting the issue as well in our logic app standard workflows... It was running normal until last night when several workflows were stuck in running stage.... Restarting will fix somehow fix it, and then work for several minutes... then again will stop triggering...

    We upgraded to next tier which is WS2 but still same symptoms...

    1. Scott Henderson 35 Reputation points

      Hi @JoelP

      this was exactly the same behaviour we saw in all of our logic apps across 3 standard WS3 ASP's. Changing the value of the environment variable AzureFunctionsJobHost_extensionBundle_Version to [1.161.25, 1.161.25] resolved this for us. Please see my full answer for more details as this is a temporary fix only.

    Sign in to comment
  4. kagiyama yutaka 3,685 Reputation points

    I think wide delays like this usually come from the region or a shared backend, and the fastest check is seeing the same slowdown window in a few run histories and sending those timestamps and run IDs to Azure Support to verify the Australia East runtime.

    1. Scott Henderson 35 Reputation points

      Thanks Kagiyama, we had assumed the same thing about the source.
      We have an active support case in with MS with those details already.

    2. kagiyama yutaka 3,685 Reputation points

      Good to hear u already shared the run‑history window with Support — I think the main thing on your side now is to watch whether new runs fall into the same latency window or if the pattern shifts, which is usually the first sign the region is recovering.

    Sign in to comment

  5. AI answer

    The described symptoms (many workflows suddenly taking far longer than normal, runs “hanging”, and only briefly recovering after restarts) match known platform-side or regional issues rather than typical workflow design problems, especially when they affect many logic apps and App Service Plans at once.

    Because no SLA exists for latency and there is no way to increase the fixed 2‑minute action timeout, the main options are:

    1. Check for regional or platform issues more deeply
      • Use Azure Monitor metrics on the affected Logic Apps to see if trigger or action latencies and failure rates spiked at the same time across multiple workflows. This helps confirm a platform or regional problem rather than a single workflow issue.
      • Review Service Health and Azure Status again, focusing specifically on Logic Apps and any dependent services (Storage, SQL, Service Bus, etc.) in Australia East.
    2. Validate that this is not a storage/connectivity health issue
      • Logic Apps (Standard) rely heavily on their associated storage account. If the storage account is unhealthy or blocked by networking/firewall rules, workflows can appear to hang and the resource can scale unexpectedly.
      • For Standard logic apps, verify that the storage account is reachable and not blocked by firewall, service endpoints, or private endpoints. Use DNS checks (nslookup) and connectivity checks (psping/tcpping) from a VM in the same virtual network if applicable, and ensure the logic app’s WEBSITE_DNS_SERVER and VNet integration are correctly configured.
    3. Check for known timeout limits and patterns
      • Individual actions (for example HTTP or SQL connector actions) have a fixed timeout of about 2 minutes that cannot be increased. If backend services are slow or intermittently unresponsive, actions will time out or runs will appear to stall.
      • For long‑running SQL stored procedures, the SQL connector’s Execute stored procedure action has a timeout limit of less than two minutes and can return 504 Gateway Timeout. If any of the affected workflows call long‑running stored procedures, consider implementing the documented asynchronous pattern (job agent + state table + completion trigger) instead of direct synchronous calls.
    4. Use Standard vs. Consumption guidance
      • For Consumption workflows, there is no latency SLA and multitenant load can cause occasional spikes in execution time.
      • For Standard workflows, ensure runtime configuration is healthy and that the underlying host is not repeatedly scaling or failing due to storage/network issues.
    5. If the issue is clearly regional/platform-wide
      • If metrics show widespread latency across many workflows and there is still no visible incident in Service Health, open a support case with Azure Support so the Logic Apps product group can investigate the Australia East region specifically.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer