☁️ Azure SQL Managed Instance Start/Stop Schedule Terraform Module

A weekly schedule of running windows for a SQL Managed Instance, so it is billed only while it is needed — targeting hashicorp/azurerm ~> 4.0.

• ⏰ Records the weekly windows in which a SQL Managed Instance runs — everything outside them is downtime.
• 🧮 Computes and emits the running and stopped hours per week, because that number is the decision and nobody derives it reliably by hand.
• ⌛ Enforces the HH:MM format the provider does not check at all.
• ⚠️ States the fact that catches everyone: the times are when the operation is initiated, not when the instance is ready.
• 🔕 Reports that a stop can be silently skipped, so a saving forecast is an upper bound.

💡 Why it matters: the schedule is not a set of maintenance events layered onto a running instance — it is the instance's uptime. A single Monday-to-Friday window means every database is unreachable all weekend. Applying this to an instance that currently runs continuously will take it offline at the first gap, which is the feature working correctly and is rarely what a reader expects on first reading.

If this module saved you time:

• ⭐ Star the repository
• 💼 Connect on LinkedIn
• ☕ Buy me a coffee

flowchart TB
    MI["terraform-azurerm-mssql-managed-instance"]
    THIS["terraform-azurerm-mssql-managed-instance-start-stop-schedule"]
    FOG["terraform-azurerm-mssql-managed-instance-failover-group"]
    ADM["terraform-azurerm-mssql-managed-instance-active-directory-administrator"]
    TDE["terraform-azurerm-mssql-managed-instance-transparent-data-encryption"]
    SRV["terraform-azurerm-mssql-server"]

    MI -->|"id"| THIS
    MI -->|"id"| FOG
    MI -->|"id"| ADM
    MI -->|"id"| TDE
    THIS -.->|"a stopped instance serves no failover role"| FOG
    SRV -.->|"logical servers cannot be stopped this way"| THIS

    style THIS fill:#0078D4,stroke:#004578,color:#ffffff
    style MI fill:#004578,stroke:#004578,color:#ffffff
    style FOG fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style ADM fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style TDE fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style SRV fill:#F3F2F1,stroke:#8A8886,color:#201F1E

Every module in this family takes the same managed instance's id; this one differs in what it does with it. The dotted edge to the failover group is the interaction worth thinking about before combining them — a stopped instance is not serving any failover role, so a schedule and a disaster-recovery pairing on the same instance are two controls with opposite assumptions. The other dotted edge is a reminder that a logical SQL server cannot be stopped this way at all.

flowchart TB
    MID["managed_instance_id (required, force-new)"]
    SCH["schedule (required, at least one running window)"]
    TZ["timezone_id (Windows zone, defaults to UTC)"]

    SS["azurerm_mssql_managed_instance_start_stop_schedule.this"]

    OID["id"]
    ORUN["running_hours_per_week"]
    OSTOP["stopped_hours_per_week"]
    ONEXT["next_execution_time"]

    MID --> SS
    SCH --> SS
    TZ --> SS
    SS --> OID
    SS --> ORUN
    SS --> OSTOP
    SS --> ONEXT

    style SS fill:#0078D4,stroke:#004578,color:#ffffff
    style SCH fill:#004578,stroke:#004578,color:#ffffff
    style MID fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style TZ fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style OID fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style ORUN fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style OSTOP fill:#F3F2F1,stroke:#8A8886,color:#201F1E
    style ONEXT fill:#F3F2F1,stroke:#8A8886,color:#201F1E

Schema notes that bite:

• 🔴 The times are when the operation is INITIATED, not when the instance is ready. Microsoft's worked example: to be available at 8 AM, schedule the start at 7:40 AM.
• 🔴 The provider applies no time-format check. start_time and stop_time carry only a non-empty check, so 9am, 09:00:00 and 25:00 all pass its validation and fail at Azure. The HH:MM rule here is the module's.
• 🔴 Microsoft documents two rules the provider does not enforce: scheduled pairs may not overlap, and any two successive actions must be at least one hour apart. The API rejects violations at apply. This module refuses the unambiguous cases and reports the rest.
• 🔴 A stop can be silently skipped. If a conflicting operation is in progress, Azure retries after ten minutes and then abandons that occurrence — the instance keeps running and nothing reports it.
• 🔴 General Purpose tier only. A Business Critical instance cannot be stopped, and this module receives only a Resource ID.
• ⚠️ schedule carries a minimum of one item, invisible in the binary schema — an empty list fails with "Not enough list items".
• ⚠️ The day names are a closed, CASE-SENSITIVE set: monday and MONDAY are both refused.
• ⚠️ timezone_id is a WINDOWS identifier, not IANA — Central Europe Standard Time, not Europe/Berlin. The provider checks only non-emptiness.
• ℹ️ There IS a requires-import guard on create, so a clean apply is evidence no schedule existed.
• ℹ️ Delete removes the schedule and leaves the instance where it is — including stopped, with nothing left to start it.
• ℹ️ No tags, no location. All four timeouts are honoured (30/5/30/30) and govern writing the schedule, not running it.

🔴 Whoever can write this resource can take every database on the instance offline, on a recurring basis, by editing four strings. It is a smaller-looking permission than it is.

ℹ️ No data-plane permission is involved. The schedule is control-plane metadata and says nothing about who may read the databases while they are up.

• The Microsoft.Sql resource provider registered on the subscription.
• An existing SQL Managed Instance in the General Purpose service tier. Business Critical instances cannot be stopped.
• A decision about the Windows time zone — UTC is the default and the only one that does not shift twice a year.
• The caller configures provider "azurerm" { features {} }, auth and subscription.

terraform-azurerm-mssql-managed-instance-start-stop-schedule/
├── providers.tf    # required_version + pinned azurerm; no provider block
├── variables.tf    # 5 inputs, deeply typed, with the format and timing rules
├── main.tf         # the single keystone `this`
├── outputs.tf      # id first, then the computed weekly hours, then the posture facts
├── README.md       # this file
├── SCOPE.md        # the cross-module contract
├── LICENSE         # MIT
└── .gitignore

provider "azurerm" {
  features {}
}

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id

  schedule = [
    {
      start_day  = "Monday"
      start_time = "07:40"
      stop_day   = "Friday"
      stop_time  = "19:00"
    },
  ]
}

That instance is now stopped from Friday evening until Monday morning — about 60 hours a week. Read example 1 before applying it to anything that currently runs continuously.

Consumes

Emits

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id

  schedule = [
    {
      start_day  = "Monday"
      start_time = "07:40"
      stop_day   = "Friday"
      stop_time  = "19:00"
    },
  ]
}

output "uptime" {
  value = {
    running = module.sqlmi_schedule.running_hours_per_week # 107.33
    stopped = module.sqlmi_schedule.stopped_hours_per_week # 60.66
  }
}

schedule = [
  {
    start_day  = "Monday"
    start_time = "07:40" # so the instance is UP by 08:00
    stop_day   = "Friday"
    stop_time  = "19:00"
  },
]

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id

  schedule = [
    {
      start_day  = "Monday"
      start_time = "07:40"
      stop_day   = "Friday"
      stop_time  = "19:00"
    },
    {
      start_day  = "Saturday"
      start_time = "08:00"
      stop_day   = "Saturday"
      stop_time  = "12:00"
    },
  ]
}

output "windows" {
  # ["Monday 07:40 -> Friday 19:00", "Saturday 08:00 -> Saturday 12:00"]
  value = module.sqlmi_schedule.running_windows
}

# ALL REFUSED at plan by this module -- and ALL accepted by the provider:
#   start_time = "9am"
#   start_time = "09:00:00"
#   start_time = "25:00"
#   start_time = "09:60"
#
# Correct:
schedule = [
  { start_day = "Monday", start_time = "09:00", stop_day = "Monday", stop_time = "17:00" },
]

# REFUSED -- same day, 30 minutes apart:
#   { start_day = "Monday", start_time = "09:00", stop_day = "Monday", stop_time = "09:30" }
#
# ACCEPTED -- exactly one hour:
schedule = [
  { start_day = "Monday", start_time = "09:00", stop_day = "Monday", stop_time = "10:00" },
]

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id
  timezone_id         = "Eastern Standard Time" # a WINDOWS identifier

  schedule = [
    { start_day = "Monday", start_time = "07:40", stop_day = "Friday", stop_time = "19:00" },
  ]
}

output "service_interpretation" {
  value = {
    next_at     = module.sqlmi_schedule.next_execution_time
    next_action = module.sqlmi_schedule.next_run_action
  }
}

output "pointless" {
  value = module.sqlmi_schedule.this_schedule_never_stops_the_instance
}

output "forecast_caveat" {
  value = {
    stopped_hours = module.sqlmi_schedule.stopped_hours_per_week
    may_be_skipped = module.sqlmi_schedule.a_stop_can_be_silently_skipped
  }
}

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id
  description         = "Dev instance: deliberately off nights and weekends. Do not extend without asking the data team."

  schedule = [
    { start_day = "Monday", start_time = "07:40", stop_day = "Friday", stop_time = "19:00" },
  ]
}

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id # a DEV instance, not the DR secondary

  schedule = [
    { start_day = "Monday", start_time = "07:40", stop_day = "Friday", stop_time = "19:00" },
  ]
}

module "sqlmi_schedule" {
  source   = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"
  for_each = module.dev_instances

  managed_instance_id = each.value.id
  description         = "Non-production: off outside working hours"

  schedule = [
    { start_day = "Monday", start_time = "07:40", stop_day = "Friday", stop_time = "19:00" },
  ]
}

output "weekly_stopped_hours" {
  value = { for k, m in module.sqlmi_schedule : k => m.stopped_hours_per_week }
}

output "any_saving_nothing" {
  value = [for k, m in module.sqlmi_schedule : k if m.this_schedule_never_stops_the_instance]
}

provider "azurerm" {
  features {}
}

data "azurerm_client_config" "current" {}

module "sqlmi_dev" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance.git?ref=v1.0.0"

  name                = "sqlmi-dev-eus2"
  resource_group_name = "rg-data-dev"
  location            = "eastus2"

  # General Purpose -- stop and start is not available on Business Critical.
  sku_name           = "GP_Gen5"
  vcores             = 4
  storage_size_in_gb = 256
  subnet_id          = var.dev_subnet_id
  license_type       = "BasePrice"
  # Both are required through this module: the provider pairs each with an
  # inline Entra administrator block that this module does not expose.
  administrator_login          = "sqladmin"
  administrator_login_password = var.mi_admin_password # out of band; never committed
}

module "sqlmi_dev_entra_admin" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-active-directory-administrator.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id
  login_username      = "sql-mi-admins"
  object_id           = var.sql_admin_group_object_id
  tenant_id           = data.azurerm_client_config.current.tenant_id
}

module "sqlmi_schedule" {
  source = "git::https://github.com/microsoftexpert/terraform-azurerm-mssql-managed-instance-start-stop-schedule.git?ref=v1.0.0"

  managed_instance_id = module.sqlmi_dev.id
  timezone_id         = "UTC"
  description         = "Dev instance: off nights and weekends to control cost"

  schedule = [
    {
      start_day  = "Monday"
      start_time = "07:40" # up by 08:00
      stop_day   = "Friday"
      stop_time  = "19:00"
    },
  ]
}

output "dev_instance_cost_posture" {
  value = {
    running_hours   = module.sqlmi_schedule.running_hours_per_week
    stopped_hours   = module.sqlmi_schedule.stopped_hours_per_week
    fraction_up     = module.sqlmi_schedule.running_fraction_of_week
    windows         = module.sqlmi_schedule.running_windows
    next_action_at  = module.sqlmi_schedule.next_execution_time
    saving_is_a_max = module.sqlmi_schedule.a_stop_can_be_silently_skipped
  }
}

Identity — managed_instance_id (required, force-new). Windows — schedule (required, at least one). Interpretation — timezone_id, description. Tail — timeouts. (There is no tags: the resource exposes none.)

🔒 No secret is accepted or emitted: this resource records times.

The windows are the uptime. That is the single idea this module is built around. A schedule entry is not a maintenance event layered onto a running instance — the instance runs between the start and the stop and is stopped the rest of the time. So the module computes running_hours_per_week and stopped_hours_per_week and puts them in front of the reader, because the hours are the decision and a list of four-field objects is not a good way to see them.

Those figures rest on a stated assumption. Week-minutes are computed with Monday as the first day, and a window whose stop falls at or before its start is treated as crossing the week boundary. The service does not publish an ordering, so the output descriptions say so and point at next_execution_time — which is Azure's own answer — as the way to check.

Two rules are enforced that the provider does not check at all. The HH:MM format comes from Microsoft's examples, not from a provider validator, and the error message says so. Microsoft's one-hour minimum between successive actions is enforced only for unambiguous same-day windows, because judging a window that may wrap the week would require the ordering the service does not publish. The rest are listed in an output rather than guessed at — the module says what it could not check.

Overlap is left to Azure. Microsoft forbids overlapping pairs and the API rejects them, but reliable detection needs the same unpublished ordering. running_hours_per_week summing past 168 is the practical hint, and this_schedule_never_stops_the_instance catches the extreme case.

The saving is an upper bound, not a forecast. A stop is skipped entirely if a conflicting operation is still running ten minutes later, and nothing reports that. Any cost model built on stopped_hours_per_week should be read as the best case.

Nothing is inverted here. timezone_id keeps the provider's UTC, which is the predictable choice; and there is no default schedule, because there is no safe one — a schedule is by definition downtime, so it must be typed.

Destroy is the reassuring direction. Deleting the schedule removes the schedule and nothing else: the instance stays in whatever state it is in. A destroy performed while the instance is stopped leaves it stopped, with nothing scheduled to start it again — worth knowing before doing it on a Friday.

terraform init -backend=false
terraform validate
terraform fmt -check

Pin the module with ?ref=v1.0.0 — never a branch. This module is plan-only in this repository; a human applies from CI.

terraform validate proves, offline and with no credentials: the anchored managed_instance_id pattern, the at-least-one-window rule, the closed case-sensitive day set, the HH:MM format on both times, the zero-length-window refusal, the same-day one-hour minimum, the IANA-time-zone refusal, and the whitespace-only description refusal.

Only terraform plan and apply exercise: whether the instance exists, whether it is General Purpose, and whether Azure accepts the windows as non-overlapping.

Nothing at either stage tells you that a stop was skipped, or that the instance is down when someone needs it. That is what next_execution_time, the computed hours and the constant outputs are for.

Note the asymmetry: a validation failure blocks terraform destroy as well as apply, which is why the timing checks are narrowed to the cases that cannot be legal rather than applied to every window.

id                       = "/subscriptions/.../resourceGroups/rg-data-dev/providers/Microsoft.Sql/managedInstances/sqlmi-dev-eus2/startStopSchedules/default"
managed_instance_name    = "sqlmi-dev-eus2"
timezone_id              = "UTC"
running_windows          = ["Monday 07:40 -> Friday 19:00"]
schedule_item_count      = 1
running_hours_per_week   = 107.33
stopped_hours_per_week   = 60.66
running_fraction_of_week = 0.6388888888888888
next_execution_time      = "2026-08-17T07:40:00Z"
next_run_action          = "Start"
force_new_fields         = ["managed_instance_id"]

• azurerm_mssql_managed_instance_start_stop_schedule
• Stop and start an instance — Azure SQL Managed Instance
• Microsoft.Sql/managedInstances/startStopSchedules template reference
• Sibling modules: terraform-azurerm-mssql-managed-instance, terraform-azurerm-mssql-managed-instance-failover-group, terraform-azurerm-mssql-managed-instance-active-directory-administrator, terraform-azurerm-mssql-managed-instance-transparent-data-encryption, terraform-azurerm-mssql-server
• This module's SCOPE.md

💙 "Infrastructure as Code should be standardized, consistent, and secure."