---
title: "Schedule automation example: turning off a VM"
slug: "simple-examples"
updated: 2026-08-05T07:16:02Z
published: 2026-08-05T07:16:02Z
canonical: "docs.turbo360.com/simple-examples"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.turbo360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Schedule automation example: turning off a VM

## Overview

This example walks through the cost impact of using Cost Analyzer schedule automation to turn off a virtual machine outside of office hours. It explains how savings are calculated, the difference between theoretical and realized savings, and the additional billing factors that affect your actual monthly reduction.

### Business value

Scheduling VMs to deallocate during non-working hours is one of the highest-impact optimizations available for compute-heavy workloads. Understanding how savings are calculated — and what reduces them — helps you set accurate expectations and configure schedules that deliver measurable results.

## How it works

When a schedule moves a VM to the stopped state, Turbo360 deallocates it rather than simply stopping it. Deallocation releases the compute allocation, which stops the per-second billing for compute and software licenses. Associated resources (disks, NICs, public IPs) continue to bill independently.

Cost Analyzer calculates theoretical savings by comparing the number of hours the resource spends in the up state versus the down state, and multiplying the difference against the hourly compute rate. Realized savings are what actually appear in your Azure invoice and may differ from the theoretical figure due to a range of factors described below.

## Example scenario

### Key points

#### Hours saved

A week has **168 hours**. If you turn the VM **off for 118 hours per week**, you run it for only **50 hours per week**.

#### Savings calculation

Linux **D16as_v4** hourly price: **$0.768/hour (East US, assumed retail rate)**

**Weekly savings:** 118 hours × $0.768 = $90.624 saved per week

**Monthly savings** (using 4.345 weeks/month): $90.624 × 4.345 ≈ **$394.00 saved per month**

That means instead of paying the full **$553/month**, you would pay closer to:

$553 − $394 ≈ **$159 for the month**

## Theoretical savings vs. realized savings

**Theoretical savings** are estimated by comparing the number of hours a resource is in an up state (turned on or scaled up) versus a down state (turned off or scaled down), against the cost if the resource stayed up the entire time. The calculation uses four parameters:

- The up cost per hour
- The down cost per hour
- The number of hours in the up state
- The number of hours in the down state

**Realized savings** reflect what actually appeared in your Azure invoice. Several factors outside the schedule itself can reduce realized savings significantly. For example, if a reservation covers the subscription containing the VM, Azure may apply that reservation to the VM for 2 hours in one month and 50 hours in another — and you cannot predict which VM in the subscription the reservation will act on for any given hour. This variability means your realized savings can differ from the theoretical estimate each month.

## Limitations

The following factors can reduce your realized savings relative to the theoretical estimate. Review each one before setting expectations for a schedule.

| Factor | Potential impact |
| --- | --- |
| Stopping rather than deallocating | ❌ Lose all savings — compute still bills when the VM is stopped but not deallocated. Turbo360 schedules always deallocate. |
| Disks, NICs, and public IPs | Moderate — these resources continue to bill regardless of VM state. They are separate billing items, not included in the schedule calculation unless they are also part of the schedule. |
| Reserved Instances | High impact — if the VM is covered by a reservation you still pay for the reservation even when the VM is off. You only save if the reservation is reallocated to another matching VM during the off hours. |
| Savings Plan commitment | Medium–high — you still pay your committed hourly spend. Turning off the VM only reduces cost beyond the commitment threshold. |
| Accidental auto-starts | Medium — any process that restarts the VM during the scheduled off window eliminates the saving for those hours. |
| Discounts vs. retail pricing | Small–medium — CSP, EA/MCA, Azure Hybrid Benefit, Spot pricing, and regional adjustments all affect the effective hourly rate and therefore the saving. |
| Billing granularity | Small — Azure bills VM compute per second, but some associated resources bill per hour. The schedule's exact start and stop times may not align perfectly with hourly boundaries. |

## Related articles

- [Managing optimization schedules](https://docs.turbo360.com/docs/managing-optimization-schedules)
- [Logic App action: before schedule runs](https://docs.turbo360.com/docs/before-schedule-runs-logic-app)
- [Logic App action: after schedule runs](https://docs.turbo360.com/docs/after-schedule-runs-logic-app)
- [Logic App action: before resource action](https://docs.turbo360.com/docs/before-resource-runs-logic-app)
- [Logic App action: after resource action](https://docs.turbo360.com/docs/after-resource-runs-logic-app)