Share via

Is it possible to restart a specific App Service worker/instance in Azure App Service (PaaS)?

Selvam Sekar 40 Reputation points
2026-05-04T10:50:13.7533333+00:00

I’m working with Azure App Service (PaaS) and trying to understand whether it is possible to restart a specific worker/instance (node) rather than restarting the entire App Service.

I understand that App Service is a PaaS offering and that the underlying VMs are abstracted by the platform. However, I see instance/worker identifiers such as HostInstanceId and RoleInstance exposed in AppServicePlatformLogs, which suggests there is some visibility into worker lifecycle events.

My questions are:

Is it supported or possible to restart a specific App Service worker/instance via:

  • Azure Portal
    • Azure CLI / PowerShell
      • Any supported API?
      If direct restart is not supported (which I suspect due to the PaaS abstraction): 
      - What is the **official Azure‑recommended way** to handle a misbehaving or unhealthy worker?

   - Is scaling (scale out / scale in) the only supported way to force worker replacement?

   From an **observability perspective**:

      - Can **AppServicePlatformLogs** reliably indicate that a worker/instance was recycled or replaced?

         - Is there any log signal or event that definitively represents a worker restart (or is it always inferred indirectly)?

Lastly, is there any Microsoft documentation or best practice that clearly explains:

  • Why instance-level restart is not exposed
    • How customers should reason about “instance restarts” in App Service compared to IaaS VMs or AKS nodes
Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

0 comments

Answer accepted by question author

  1. Golla Venkata Pavani 4,095 Reputation points Microsoft External Staff Moderator
    2026-05-04T13:35:24.1566667+00:00

    Hi @Selvam Sekar

    Thank you for reaching us regarding the issue.

    Yes, you can restart a specific worker/instance in Azure App Service without restarting the entire app or plan.

    1. Is it supported or possible to restart a specific App Service worker/instance via:
    • Via Azure Portal (Recommended for Manual Restarts)
      After enabling Health check (under Monitoring for your App Service app):
      • Navigate to the Instances tab.
      • View instance names and health status (Healthy/Unhealthy).
      • Select Restart for a specific instance. This performs an advanced application restart on that worker process.

    This performs a targeted restart of the application worker on that instance. If the restart doesn’t resolve the issue, you’ll often get an option to Replace the worker (subject to platform limits: 1 per hour / 3 per day per plan).

    • Via REST API (for CLI/PowerShell/Scripting)
      Use the Reboot Worker API on the App Service Plan: 
        POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/microsoft.Web/serverfarms/{name}/workers/{workerName}/reboot?api-version=2025-05-01
      The workerName usually starts with “RD” and can be found in the Instances blade or platform logs.

    Recommended Approach (Best Practice)

    For production workloads, Microsoft recommends designing for resilience instead of frequent manual restarts:

    • Enable Health Check so unhealthy instances are automatically removed from the load balancer.
    • Use Auto-Heal rules for automatic process recycling based on memory, CPU, or request failures.
    • Scale out to at least 2–3 instances so traffic can shift seamlessly while the platform handles recovery.

    Observability with AppServicePlatformLogs:
    Logs platform events like worker process starts, recycles, stops, and Auto-Heal actions. Use them to infer restarts (e.g., a new “Worker Process launched” after recycle). No single definitive restart event, correlate with metrics, HTTP logs, and the Instances view for a complete picture.

    Why instance-level restart is not exposed:

    In Azure App Service (PaaS), Microsoft manages the underlying infrastructure, handling maintenance, patching, and recovery, so you don’t control individual instances directly. Instance-level actions (like restart/replace) are mainly for troubleshooting, while the platform relies on built-in healing (Health Check, Auto-Heal, overlapped restarts) to maintain availability. For resilience, designs focus on multi-instance deployments with automatic recovery rather than manual instance control.

    Reference:
    https://learn.microsoft.com/en-us/rest/api/appservice/app-service-plans/reboot-worker?view=rest-appservice-2025-05-01
    https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check?tabs=dotnet
    https://learn.microsoft.com/en-us/azure/app-service/routine-maintenance-downtime

    If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

    If you have any other questions, let me know in the "comments" and I would be happy to help you

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-04T10:50:42.7266667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Restarting a specific worker/instance in Azure App Service (PaaS) is not exposed as a supported operation in the provided documentation. The platform abstracts the underlying workers and handles restarts and replacements as part of its maintenance and failure‑recovery processes.

    The documented, supported ways to handle misbehaving or unhealthy workers and performance/availability issues are:

    1. Scale the app
      • Scale up to a higher App Service plan pricing tier.
      • Scale out to run on more than one instance for additional processing capacity and fault tolerance.
      • Scaling out ensures that if the process goes down on one instance, other instances continue to serve requests.
      • Scaling can be manual or automatic.
    2. Use Auto-Heal
      • Auto-heal recycles the worker process for the app based on configured triggers such as configuration changes, request patterns, memory limits, or long‑running requests.
      • Recycling the process is described as the fastest way to recover from many problems.
      • Auto-heal is configured via settings (for example, in the root web.config) and works even if the app isn’t .NET.
    3. Restart the app
      • Restarting the entire app from the Azure portal is explicitly documented as a simple way to recover from one‑time issues.
      • The same restart operation can be performed via Azure PowerShell (managing the app as a resource), but still at the app level, not per worker.
    4. Use Health Check and Auto-Heal for uptime and startup resiliency
      • Health Check can remove a failing instance from the load balancer and replace an entire instance when it is unhealthy, minimizing downtime.
      • Auto-Heal can automatically restart the worker process when certain failure conditions are met, including unrecoverable states after startup.
    5. Platform maintenance and unexpected failure handling
      • During planned maintenance, App Service updates instances in waves and swaps in updated instances, causing application starts/restarts but avoiding maintenance on in‑use servers.
      • For unexpected hardware or file server failures, the platform replaces affected roles and restarts worker processes on the new roles.
      • These behaviors are managed by the platform; customers do not directly restart individual workers.

    From an observability and reasoning perspective:

    • The documentation explicitly describes that application restarts occur as part of maintenance and failure handling, and that there can be multiple restarts per instance in a plan during an update cycle.
    • Health Check and Auto-Heal are the recommended mechanisms to detect and react to unhealthy instances (removing them from the load balancer or restarting processes), rather than manual per‑instance restarts.
    • The provided documents do not describe a specific log event or field in AppServicePlatformLogs that directly exposes a “worker restart” operation; instead, they describe restarts and instance replacements as platform behaviors and recommend using Health Check and Auto-Heal to manage and mitigate their impact.

    In terms of best practices and conceptual guidance:

    • App Service is positioned as a PaaS where customers focus on application code while the platform manages underlying infrastructure, including maintenance, restarts, and failure recovery.
    • The recommended way to think about “instance restarts” is via:
      • Platform‑driven restarts during maintenance or failure recovery.
      • Application‑level mitigations such as scaling, Health Check, and Auto-Heal to maintain uptime and handle unhealthy instances.
      • App‑level restarts (not per‑worker) when manual intervention is needed.

    The documentation in the provided context does not expose or endorse any mechanism to restart a specific worker/instance, and instead emphasizes scaling, Health Check, Auto-Heal, and app‑level restart as the supported and recommended approaches.

    References:

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.