Are SIGTERM/SIGINT signals sent on scale-in events for App Service?

Hello Matt,

Thank you for submitting your question on Microsoft Q&A.

If you manually stop or restart an Azure App Service, your container receives a SIGTERM signal. However, during a scale-in event, the platform focuses on quickly removing the instance from the load balancer and freeing up resources, which may lead to the instance being terminated abruptly without a SIGTERM signal.

Intended Way to Run Cleanup

Since signals may not be reliable during scale-in, it's best to design your application to be stateless and avoid complex in-memory cleanup. For tasks that must be completed before shutdown, use a health check endpoint.

1. Implement a Health Check Endpoint: Add an endpoint (e.g., /health) that returns a 200 OK status when your app is ready.
2. Graceful Shutdown via Health Check: When cleanup is needed, have your app return an "unhealthy" status (such as 503 Service Unavailable) from the health endpoint. Azure will then stop sending new requests to your instance.
3. Perform Cleanup: After marking the app as unhealthy, your application has a short window to finish any ongoing requests and complete cleanup before shutting down.

Also, consider using external state management tools like Azure Cache for Redis or Azure Storage. This way, if your data isn't stored in-memory, unexpected shutdowns won't cause data loss.

How to Debug

If you think there may be an issue with signals, check the following:

• Entrypoint Process: Make sure your Node.js app is running as the main process (PID 1) in the container. If you use a shell script as the ENTRYPOINT, the shell might receive the SIGTERM and not pass it to Node.js. Using exec to start Node.js as PID 1 can help.
• Logging: Enable and review all logs in Azure App Service, including Container Logs and Application Logs, to identify any unusual messages during scale-in.

Please refer to the document links below.

https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/faqs-app-service-linux

https://learn.microsoft.com/en-us/azure/app-service/manage-scale-up

https://github.com/dotnet/dotnet-docker/blob/main/samples/kubernetes/graceful-shutdown/graceful-shutdown.md

https://learn.microsoft.com/en-in/azure/well-architected/service-guides/app-service-web-apps

https://learn.microsoft.com/en-us/answers/questions/1125435/extend-timeout-for-graceful-shutdown-in-azure-app

Hi @Srikanth Reddy Bandi

Thanks for the detailed response. However what you've suggested works for scaling out but not scaling in. There are so many cases where scale in rules are external to the app itself. It's not necessarily about an instance being healthy or not, but rather than resources have now become available somewhere else.

Consider the following example:

• We set up autoscale rules so that a new instance is added when the average CPU is at 80%.
• Load increases gradually and the following scale out events occur:
  • Instance 1 reaches 80%, triggers scale out
  • Instance 2 reaches 80%, triggers scale out
  • Instance 3 reaches 80%, triggers scale out
• At this point we have instances 1, 2, 3 all at 80%.
• Eventually, load decreases on instance 1 and our scale in rule is triggered. As per the scale-in policy instance 3 is removed.
  • At this point instance 3 is still healthy, but resource has become available somewhere else.
  • Instance 3 needs to be removed from the load balancer, but it should still receive a SIGTERM so that it can finish what it's doing. For example it could be in the middle of running a process when it's abruptly removed from the load balancer.

I hope this is clear enough. This is the exact scenario that is happening to us. This type of scale-in behaviour makes autoscale rules pretty much unusable for us because the processes we have in flight are getting abruptly cut off without any warning.

Thanks for your detailed explanation—you're absolutely right to expect that a container should receive a SIGTERM during scale-in to allow for graceful shutdown. Here's what the latest findings confirm:

✅ Current Behavior in Azure App Service (Linux Containers)

1. Manual Stop/Restart: When you manually stop or restart an Azure App Service running a Linux container, the platform does send a SIGTERM to the container, allowing your app to handle it via process.on('SIGTERM') or similar handlers https://learn.microsoft.com/en-us/answers/questions/5535739/are-sigterm-sigint-signals-sent-on-scale-in-events
2. Scale-In Events (Autoscale or Manual): During scale-in, SIGTERM is not reliably sent. The instance is often removed from the load balancer and terminated abruptly without the opportunity for graceful shutdown
3. Why This Happens: Azure App Service prioritizes fast resource deallocation during scale-in. This means the container may be stopped without the usual shutdown sequence, especially if the container is not PID 1 or if the entrypoint script doesn't forward signals properly https://stackoverflow.com/questions/76737584/how-to-configure-azure-web-app-container-graceful-shutdown

🛠️ Workarounds and Recommendations

1. Ensure Your App is PID 1

If your Node.js app is not the main process (PID 1), it might not receive signals. Use exec in your Docker ENTRYPOINT to ensure Node is PID 1:

ENTRYPOINT ["sh", "-c", "exec node index.js"]

2. Use a Signal-Forwarding Entrypoint Script

If you use a shell script as the entrypoint, make sure it traps and forwards SIGTERM:

#!/bin/bash

cleanup() {

  echo "Received SIGTERM, cleaning up..."

  # your cleanup logic here

  exit 0

}

trap cleanup SIGTERM

# Start your app

exec node index.js

3. Health Check + Pre-Drain Strategy

Although not perfect for scale-in, you can:

• Implement a /health endpoint.
• Return 503 to mark the instance as unhealthy.
• Wait for Azure to stop routing traffic.
• Then perform cleanup.

This works better for scale-out or manual draining, but not for autoscale scale-in, which is externally triggered.

⚠️ Known Limitation

As confirmed in GitHub discussions, Azure Web Apps (App Service) do not guarantee SIGTERM on scale-in

This is a platform limitation, not a bug in your app. https://github.com/microsoft/azure-container-apps/issues/802

✅ What You Can Do

• Vote or comment on this GitHub issue or similar threads to raise visibility.
• Consider Azure Container Apps or AKS if you need full control over lifecycle events and signal handling.