Scheduling SQL Server on Azure VM
Can ZopNight schedule SQL Server on Azure VM?
Deallocating a SQL Server VM on schedule stops both meters at once: the compute charge and the pay-as-you-go SQL Server license billed with it, which on Enterprise edition can exceed the VM cost several times over. SQL Agent jobs scheduled for 2am silently miss, and disks bill through the stop.
How the stop works
| Field | Value |
|---|---|
| Behaviour | the underlying VM is deallocated on stop and started on start, halting compute billing. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
The license meter is the headline
A pay-as-you-go SQL Server image bills its license by the second alongside the VM, and for Enterprise edition the license line can be several times the compute line. Deallocation stops both. That multiplier makes SQL VMs disproportionately rewarding to schedule. The same off-hours window saves more per hour here than on an identical VM without SQL, and that is why they belong at the top of any scheduling backlog ordered by return.
Azure Hybrid Benefit changes the math
VMs licensed through Hybrid Benefit bring their own SQL license, so only compute stops billing on deallocation. The schedule still pays, just at the ordinary VM rate. Check which licensing model each VM uses before promising numbers; the same size VM saves wildly different amounts under the two models.
SQL Agent sleeps through its jobs
Backups at 2am, index maintenance at 3am, DBCC checks on Sundays: SQL Agent jobs live inside the instance, and a deallocated instance runs none of them. Missed jobs do not queue or catch up. Every scheduled SQL VM needs its maintenance calendar moved inside the powered-on window, typically to just after the morning start or just before the evening stop, and the first week should verify the jobs actually ran.
Deallocate, and only deallocate
The saving depends on releasing the compute allocation. A guest-OS shutdown from inside Windows leaves the VM allocated and billing both meters. The schedule issues the deallocation through Azure, which is the only stop that reaches the invoice.
Premium disks underneath keep billing at their provisioned size either way, and on database VMs those disks are rarely small, so count them in the overnight floor.
Availability groups need a harder look
A VM participating in an availability group is not a casual scheduling candidate: deallocating a replica breaks synchronization and can trigger failovers. Standalone dev and test instances are the natural fleet; scheduling AG members is a deliberate architectural decision, not a cost tweak.