Azure App Service (Linux) restarting daily without Activity Log or deployment events

Hi @Kuhu Gor ,

Thanks for reaching out in Microsoft Q&A forum,

Based on the information you've shared, the observed behavior is consistent with Azure App Service platform-initiated maintenance, infrastructure updates, or worker reallocation, rather than an application crash or deployment-related restart. The available evidence including the absence of Activity Log entries, an unchanged deployment version, clean container startup, and changing worker names strongly suggests that the restarts are being initiated by the Azure platform. However, without access to internal Azure platform telemetry, the exact trigger cannot be confirmed.

From your observations:

• The SiteStarted events occur at approximately the same UTC time each day.
• There are no corresponding Activity Log entries for restart, deployment, configuration changes, or scale operations.
• The container starts cleanly each time, with no out-of-memory conditions, application crashes, or unexpected termination events.
• The deployment version remains unchanged after each startup.
• The worker (machine) name changes, indicating that the application is being scheduled onto a different underlying worker.
• The App Service is running on a single instance, and Health Check is not currently enabled.

This pattern is consistent with Azure App Service infrastructure maintenance, platform updates, or worker reallocation. During these platform operations, Azure may stop and restart the site, recreate the application container, or move the application to a different worker while preserving the application content, configuration, and deployment package.

• Because these are platform-managed operations rather than user-initiated control plane actions, they typically do not appear as explicit restart or configuration change events in the Azure Activity Log. Instead, they are commonly observed as SiteStarted events accompanied by a clean container startup.

Since your App Service is running on a single instance, a brief period of downtime is expected during these operations because there is no secondary instance available to continue serving traffic while the underlying worker is being updated or replaced.

Is there anything else you should investigate?

Based on the information provided, there is currently no indication that these restarts are being caused by your application, deployment pipeline, or configuration changes.

To continue validating this behavior without a paid Azure Support plan, you can:

• Review Diagnose and Solve Problems, particularly the Web App Restarted detector and Availability and Performance detectors.
• Correlate the restart times with Log Stream and container logs to verify that each startup follows the same clean initialization sequence.
• Monitor Azure Monitor metrics such as CPU, Memory, Requests, and HTTP response codes around the restart window.
• Review Resource Health and Azure Service Health for any reported platform events that align with the observed restart times.

These built-in tools can help determine whether the observed behavior continues to align with expected platform operations.

If minimizing downtime during platform operations is important for your workload,

• Scaling the App Service to two or more instances, allowing Azure to perform maintenance with minimal impact by serving traffic from another healthy instance.
• Enabling Health Check and configuring it with a lightweight endpoint so that only healthy instances receive traffic during worker transitions.
• Enabling Always On (where supported by your App Service plan) to help reduce cold-start time following worker moves or platform maintenance.

For more information, please refer to the following Microsoft documentation:

• Routine Maintenance, Restarts, and Downtime - Azure App Service | Microsoft Learn
• Reliability in Azure App Service | Microsoft Learn
• Troubleshoot with Diagnostics - Azure App Service | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.