VMSS instances unexpectedly stopped with no caller-bearing Activity Log event

Lisa Alexander 0 Reputation points Microsoft Employee
2026-08-14T19:59:14.3533333+00:00

Affected instances:

  • aks-sys01-xxxxxxx-vmss/0 at 2026-08-07 23:02:30 UTC
  • aks-gen04-xxxxxxx-vmss/0 at 2026-08-07 23:04–23:05 UTC
  • aks-gen04-xxxxxxx-vmss/1 at 2026-08-08 01:04:49 UTC

Resource Health identified the events as “UserInitiated:

Stopping and deallocating,” but subscription-wide Activity Logs contain

no corresponding Administrative operation or caller.

Please use Compute backend telemetry to identify:

  1. The user, service principal, managed identity, or platform component that requested each deallocation.
  2. The API/control-plane path used.
  3. Why no caller-bearing Administrative Activity Log event was generated.
  4. Whether AKS RP or another Microsoft-managed process initiated it.
Azure Virtual Machine Scale Sets
Azure Virtual Machine Scale Sets

Azure compute resources that are used to create and manage groups of heterogeneous load-balanced virtual machines.

0 comments No comments

1 answer

Sort by: Most helpful
  1. Allan Solomon Mejia 6,240 Reputation points
    2026-08-14T20:53:51.4533333+00:00

    Hello @Lisa Alexander

    The key detail here is that Resource Health reports “UserInitiated – Stopping and deallocating.” Microsoft documents VirtualMachineDeallocationInitiated as an informational event indicating that an authorized user or process requested the deallocation. So UserInitiated doesn't necessarily mean a human manually stopped the VM.

    Since these VMSS instances appear to be AKS nodes, I would specifically check the AKS node pool scaling configuration and cluster autoscaler. AKS can deallocate VMSS instances during scale-down when the node pool's scale-down-mode is configured as Deallocate.

    For example, check:

    az aks nodepool show \
      --resource-group <AKS-RG> \
      --cluster-name <AKS-Name> \
      --name <NodePool> \
      --query "{count:count,autoscaling:enableAutoScaling,min:minCount,max:maxCount,scaleDownMode:scaleDownMode}"
    

    Also correlate the timestamps with node-pool scaling/autoscaler activity and query the Activity Log at both the VMSS and AKS-managed resource group levels rather than only looking at the individual instance.

    The absence of a caller-bearing Administrative event is important. Resource Health and Administrative Activity Logs are different event categories, and the Resource Health event itself won't necessarily identify the originating identity/API call.

    If you've confirmed there was no AKS autoscaler/node-pool operation, scheduled automation, policy, runbook, pipeline, or other management process at those exact UTC timestamps, then your request for backend correlation is reasonable. At that point, I would open an Azure support case and provide the VMSS resource IDs, instance IDs, exact UTC timestamps, Resource Health event/correlation IDs, and relevant AKS cluster/node-pool details. Microsoft Support can correlate those with internal Compute/AKS telemetry; this isn't something the community forum can retrieve.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    Was this answer helpful?


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.