Share via

Function App in Azure stopped working on May 6th

Pea Creamer 0 Reputation points
2026-05-15T09:24:22.8433333+00:00

We are developing a webshop and have some node.js component hosted in Azure. We are using West Europe.

The app stopped working May 6th, about 00:30 CET. About 08:00 the developers could get the app started for some 5 minutes, then stopped working again.

App Service plan was running on Y1 which got an EoL announcement that very day for 2027 or 2028. But it appears that the plan was also removed from existing tenants so our app could not run anymore Only by ordering a new plan P2V3 and moving our code we could use the app again after 24hrs. Since then working again flawlessly, but not really convinced it won't happen again.

We can see in the logs, that and when the app stopped working, but we cannot make out any cause.

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.


3 answers

Sort by: Most helpful
  1. Pravallika KV 16,365 Reputation points Microsoft External Staff Moderator
    2026-05-20T10:10:10.9366667+00:00

    Hi @Pea Creamer ,

    It looks like the root cause here was the Y1 (free/consumption-like) App Service plan being removed unexpectedly from your tenant. When that plan vanished on May 6th, your Function App had nowhere to run, so it went down until you re-provisioned on P2V3. Moving to P2V3 was the right call, but to be extra sure you won’t run into a similar surprise, here’s what I’d recommend:

    1. Migrate to a supported App Service SKU
    • Use at least a P1V3/P2V3 (or Premium/Elastic) plan. These SKUs won’t be removed without plenty of warning.
    • Turn on Always On in Platform Features so your host stays warm and you avoid cold starts.
    1. Monitor and size for memory usage
    • Error codes 134 and 137 mean your process was OOM-killed. In Kudu you can inspect memory spikes under D:\home\LogFiles\Application\Functions or via Performance Counters in App Insights.
    • In Application Insights, try a query against performanceCounters to see memory trends:
         performanceCounters  
         | where counterName == "\Process\Private Bytes" and timestamp > ago(1d)  
    
    1. Keep your runtime supported
    • You’re already on Functions Runtime v4 - perfect. If you ever need to change it, go to Configuration > Function runtime settings.
    1. Use Application Insights and Activity Log for deep debugging
    • To catch host-level restarts or config changes, run:
         traces  
         | where message contains "Host configuration has changed" or message contains "Signaling restart"  
    
    • To surface errors at the outage time:
         traces  
         | where timestamp between (datetime(2023-05-06T00:00:00Z) .. datetime(2023-05-06T01:00:00Z))  
         | where severityLevel == "Error"  
    
    1. Configure autoscale if your webshop has traffic bursts
    • In your App Service Plan, set scale-out rules based on CPU or memory thresholds to add instances before you hit OOMs.

    Hope this helps!


    If the resolution was helpful, kindly take a moment to click on User's imageand click on Yes for was this answer helpful. And, if you have any further query do let us know.

    Was this answer helpful?


  2. Sina Salam 29,846 Reputation points Volunteer Moderator
    2026-05-16T14:54:16.3666667+00:00

    Hello Pea Creamer,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that your Function App in Azure stopped working on May 6th.

    The Function App failed because the custom container didn’t become “ready” fast enough after a cold start, so the Azure platform’s startup/readiness checks timed out and the Functions host never finished initializing.

    Follow the below procedures to resolve the issue:

    1. Set the App Setting below to allow enough time for slow cold starts and make sure these core settings exist: WEBSITES_CONTAINER_START_TIME_LIMIT = 1800 FUNCTIONS_WORKER_RUNTIME = python FUNCTIONS_WORKER_RUNTIME is a standard app setting used by Azure Functions to determine the language worker (when applicable). If you’re using extension bundles (common for non-.NET apps), keep them on the supported v4 range:
         {
         "version": "2.0",
         "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle",
          "version": "[4.0.0, 5.0.0)"
         }
         }
      
      v4 is the active extension bundle line and is recommended for best reliability/supportability. This setting extends the maximum time the platform waits for your container to respond to warm-up/readiness pings before it restarts the container. - https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings, https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/faqs-app-service-linux-new NOTE: After changing app settings, restart the Function App to apply the change. https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings
    2. On Elastic Premium (EP), configure Always Ready / pre-warmed instances ≥ 1 so the app doesn’t drop to a full cold start state. This is one of the core Premium features designed to reduce cold starts. https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan, https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
    3. Avoid shutting down the Function App nightly. Stopping the app forces a full cold start later, which increases the chance of hitting readiness/startup limits and delays host initialization. Premium plans are designed to run with at least one active instance anyway. - https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan, https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings If cost control is the goal, use safer options such as: - lowering the minimum instance count (while keeping 1 warm instance if you need reliability) - autoscale rules, - right-sizing the EP SKU These approaches preserve availability and reduce the “cold start penalty.”
    4. To reduce future cold start risk:
    5. Errors like “Custom storage volume(s) failed to initialize” often point to storage/network/DNS/SMB mount issues that can slow or block startup. Check:
      • Azure Files latency/availability
      • VNet integration + DNS resolution
      • Private Endpoint/firewall rules
      • SMB (445) reachability where applicable
      Functions on Premium commonly depend on Azure Files for content/host operations, so storage access issues can prevent the runtime from starting. - https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations, https://learn.microsoft.com/en-us/azure/azure-functions/functions-recover-storage-account
    6. Turn on:
      • Application Insights / Azure Monitor logging
      • Function host logs AND container logs where available
      Application Insights is the primary supported way to collect function execution + host telemetry and troubleshoot initialization failures. - https://learn.microsoft.com/en-us/azure/azure-functions/configure-monitoring, https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings

    I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.


    Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

    Was this answer helpful?


  3. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.


    Comments have been turned off. Learn more

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.