Virtual Machine Auto-shutdown: No webhook configured — Unable to save settings and scheduled shutdowns not working

Question

Virtual Machine Auto-shutdown: No webhook configured — Unable to save settings and scheduled shutdowns not working

Ralph Street 0

Problem description

I am experiencing issues with the auto-shutdown feature on my Azure Virtual Machines running Windows. The Auto-shutdown blade in the Azure portal displays the message 'No webhook configured', and I am unable to view or change the shutdown settings. Additionally, VMs that already have auto-shutdown enabled are not shutting down at their scheduled times. I want to understand why this message appears, how to fix the issue, and ensure that scheduled shutdowns function correctly. Notifications are Disabled, and hasWebhook: false on every schedule

Environment

Multiple Azure Virtual Machines running Windows, managed through the Azure portal, specifically the per-VM Auto-shutdown settings blade.

What I've already tried

I have attempted to update the notificationSettings to disable webhooks and also tried to recreate the auto-shutdown schedule resources. Despite provisioning success messages, the portal still shows 'No webhook configured' and does not allow saving changes. I have also verified that webhooks and notifications were not previously used in my setup, indicating that this behavior is unexpected.

Current status

Repairing or recreating the auto-shutdown schedule resources does not remove the 'No webhook configured' message.

Karsten von Lübken 0 Reputation points

2026-10-22T09:52:37.35+00:00

I'm in the same situation where I can no longer save settings for Virtual Machine Auto-shutdown in the portal and I'm really curious about the solution.

1 answer

Your answer

Karsten von Lübken 0 Reputation points

2026-10-22T09:52:37.35+00:00

I'm in the same situation where I can no longer save settings for Virtual Machine Auto-shutdown in the portal and I'm really curious about the solution.

Answer 1

Hello Ralph Street

No webhook configured message should not prevent VM auto-shutdown. Webhooks are optional and used for notifications only. When notifications are disabled, hasWebhook=false is expected.

Azure VM auto-shutdown uses Microsoft.DevTestLab/schedules resources, so I recommend checking the underlying schedule rather than relying on the portal.

Verify the existing schedule

az resource show \
  -g <RESOURCE_GROUP> \
  -n shutdown-computevm-<VM_NAME> \
  --resource-type Microsoft.DevTestLab/schedules \
  --api-version 2018-09-15 \
  --query "properties"

Confirm these properties:

status: Enabled
taskType: ComputeVmShutdownTask
targetResourceId: matches the VM's actual resource ID
dailyRecurrence.time and timeZoneId: correct

Test configuration outside the portal

You can use Azure CLI to configure auto-shutdown without a webhook:

az vm auto-shutdown \
  -g <RESOURCE_GROUP> \
  -n <VM_NAME> \
  --time 2300

This configures shutdown at 23:00 UTC. Adjust the time to your requirement.

Documentation: Configure VM auto-shutdown

Check a related reported issue

There is an open Azure GitHub issue from September 2026 reporting that the Microsoft.DevTestLab/schedules API does not return notificationSettings.webhookUrl correctly, including when configured through the portal.

GitHub issue #46146

This may explain the portal's webhook behavior, but it does not confirm the cause of missed shutdowns.

If shutdown still doesn't execute

Check the VM's Activity Log around the scheduled time for stop/deallocate operations.

If no operation appears despite a correctly enabled schedule, I would open an Azure Support request to investigate the DevTestLab scheduling backend. Include the schedule resource ID, affected VM IDs, region, and missed shutdown timestamps.

If reliable scheduled shutdown is urgently required, Microsoft's Start/Stop VMs v2 provides an alternative with scheduled execution and monitoring.

The missing webhook itself is not the problem. The important distinction is whether the underlying schedule is correctly configured but fails to execute, or whether the portal is failing to manage the schedule correctly.