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.

Update:

Thank you for the explanation. One point I'd like to clarify is that we are observing this pattern every day at approximately the same UTC time in both our Test and Production App Services. Is a daily worker recycle or platform maintenance expected behavior for a single-instance Linux App Service, or would you consider this frequency unusual? We understand that planned maintenance can cause restarts, but we would like to know whether daily restarts are expected under normal Azure App Service operations.

Based on the pattern you described, Azure App Service does not publish or guarantee a fixed schedule for platform maintenance or worker recycling. Therefore, while platform-managed operations can result in application restarts, we cannot confirm that a daily restart at approximately the same UTC time is expected behavior under normal App Service operations.

Since both your Test and Production App Services exhibit the same pattern, and there are no indications of application crashes, deployment activity, configuration changes, or scale operations, the available evidence continues to suggest that the restarts are more likely related to platform-managed operations than to an issue within your application or deployment process. However, without access to internal Azure platform telemetry, we cannot definitively determine the exact cause of the recurring daily pattern.

• We recommend continuing to correlate the restart timestamps with Resource Health, Azure Service Health, and the Web App Restarted detector in Diagnose and Solve Problems to identify any recurring platform events. Because your applications are running as single instances, any platform-initiated recycle or worker move will result in a visible restart and a brief period of downtime.
• If minimizing the impact of these events is important, scaling the App Service to two or more instances is the recommended approach, as it allows platform maintenance to occur with minimal interruption to application availability

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 do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.