Azure Automation and Start/Stop VMs v2: What You Maintain
Microsoft's scheduled start/stop has moved from Automation runbooks to a Functions app you deploy and own. This page is about running it day to day, from Microsoft's docs.
This page goes deep on the deployable options: Azure Automation runbooks and the Start/Stop VMs v2 add-on. For the per-VM auto-shutdown setting and a quick side-by-side, see Azure auto-shutdown and Start/Stop VMs v2 vs ZopNight.
Three generations of the same idea
- Your own Automation runbook. You write a PowerShell or Python runbook that starts or stops VMs and link it to a schedule.
- Start/Stop VMs during off-hours (v1). Microsoft’s packaged version, built on Azure Automation. Microsoft’s changelog says v1 “is deprecated and unavailable in the marketplace now” (What’s new in Azure Automation).
- Start/Stop VMs v2. A redesign that “doesn’t depend on Azure Automation or Azure Monitor Logs”. It relies on Azure Functions instead (v2 overview).
If you write your own runbook
The limits come from Azure Automation itself:
- Hourly at best. “The most frequent interval for which a schedule in Azure Automation can be configured is one hour.” For shorter intervals Microsoft suggests stacking several hourly schedules (schedules).
- Daylight saving is handled. The same page says Automation “supports Daylight Savings Time and schedules it appropriately”.
- Three-hour ceiling. Under the “fair share” rule, Azure “temporarily unloads or stops any job that has run for more than three hours” (runbook execution). A loop over a large VM fleet needs to finish or checkpoint in that time.
- Cost. Each month 500 minutes of job run time are free, and you pay only for minutes beyond that (Automation pricing).
Everything else is yours to write: which VMs to target, error handling, retries, logging and alerts.
What Start/Stop VMs v2 puts in your subscription
Deploying v2 needs Owner permission on the subscription. It creates:
- A Function app with a managed identity. The functions include
Scheduled,AutoStop,VirtualMachineRequestOrchestratorandVirtualMachineRequestExecutor, plus timer functions for health checks and for Microsoft’s aggregate cost and savings estimates. - Five Logic Apps: scheduled start, scheduled stop, sequenced start, sequenced stop, and AutoStop.
- A storage account, using Table Storage for operation metadata and Queue Storage for the queue-triggered functions.
- Application Insights for traces, with a shared dashboard and email notifications.
Configuring a schedule means editing JSON. In the Logic App designer you open the Recurrence step to set the time, then edit the Function-Try request body to set the scope: subscriptions, resource groups or a VM list, with an ExcludedVMLists array that accepts wildcards (deploy guide). Exclusions work for subscription and resource group scopes; the VM list scope “doesn’t support specifying a list of VMs to exclude”. The guide carries a warning worth repeating: if you give no start date for the first recurrence, it “will immediately run when you save the logic app”, which can start or stop VMs straight away.
Keeping it current is on you. v2 is in maintenance mode: “No further development, enhancements, or updates will be available for Start/Stop v2 except when required to remain on supported versions”. The auto-update functions are deprecated. Microsoft now advises stopping the site, installing the latest version from GitHub, and starting it again, and it notes there is no built-in notification when an update ships. The app moved to the .NET 8 isolated worker model on 19 August 2024.
When v2 is enough
If your scope is Azure VMs, your team is comfortable in the Logic App designer, and you can live with a product that gets only supportability fixes, v2 does the job. It runs entirely in your tenant and costs only the Functions, Logic Apps and storage it uses.
What ZopNight changes
- No infrastructure to own. Schedules are set in a UI, API or MCP with a cron expression and an IANA timezone, then attached to resources or groups. There is no Function app to patch.
- Beyond VMs. The same schedule can cover AKS clusters, MySQL and PostgreSQL flexible servers, Synapse SQL pools, Data Explorer clusters, SQL VMs and Databricks, plus resources in AWS and GCP. See PostgreSQL flexible server scheduling.
- Whole tenants. A tenant-scoped Azure connection discovers every subscription it can reach and adds each one as its own account.
- Exceptions without editing JSON. An override keeps a resource on, or forces it off, for a set window with a reason, then expires on its own. See override policies.
- A record of every run. Each start and stop is logged with its trigger (a schedule, a named user or an override), and failures can alert Slack, Teams, Google Chat or a webhook.
| ZopNight | Start/Stop VMs v2 | Own Automation runbook | |
|---|---|---|---|
| Runs where | ZopNight service | Functions, Logic Apps, storage in your subscription | Automation account in your subscription |
| Scope set by | Attaching resources or groups | JSON request body in each Logic App | Your code |
| Updates | Managed by ZopNight | Manual reinstall; maintenance mode | Your responsibility |
| Resource types | VMs, AKS, flexible servers, Synapse and more, across three clouds | Azure VMs | Whatever you script |
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Is Start/Stop VMs v2 still supported?
It is in maintenance mode. Microsoft says no further development, enhancements or updates will be available except when required to stay on supported versions of its components and Azure services.
Can I exclude VMs in Start/Stop VMs v2?
Yes, when the scope is a subscription or resource group: the request body takes an ExcludedVMLists array that accepts wildcards. A scope defined as a list of VMs does not support exclusions.
How often can an Azure Automation schedule run?
At most once an hour. Microsoft suggests creating several hourly schedules offset from each other if you need a runbook to run more often.