MySQL Flexible Servers with zero active connections that should run on an off-hours schedule

Why stopping a Flexible Server once is not enough

A Flexible Server can be stopped to pause compute billing, but only for a while. Microsoft’s stop and start guide says a server that stays stopped for 30 days in a row is started automatically, billing resumes, and it is not permissible to keep a server stopped longer than that. A server with read replicas cannot be stopped until the replicas are dropped or promoted.

So a quiet server needs a repeating pattern, not a single action. A development database nobody connects to overnight or at weekends can be stopped every evening and started every morning, and the 30-day limit never comes into play.

Checking connections and CPU on a server

az mysql flexible-server list \
  --query "[].{name:name, rg:resourceGroup, state:state, sku:sku.name}" -o table

az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/my-rg/providers/Microsoft.DBforMySQL/flexibleServers/my-server \
  --metric active_connections cpu_percent \
  --aggregation Average Maximum --interval PT1H --offset 30d

A connection average of zero across the month, with CPU in the low single digits, is the pattern.

Idle evidence ZopNight requires

1. Azure Monitor has an Active Connections series for the server covering at least 7 days, so a server restored a few hours ago is not judged on its first quiet stretch.
2. The connection average is zero. Any connections at all in the data rule the server out.
3. If CPU data exists, it averages below 2%.
4. Neither check is limited to the latest 30 days: activity anywhere in the metric history ZopNight holds vetoes the idle verdict.
5. ZopNight has measured idle hours for the server in its activity heatmap, and the server has a monthly cost.

Servers that are left running

A server that already follows a known recurring off-hours schedule is not flagged again. Without a connection series ZopNight does not assume the server is idle; the rule needs the metric, not a tag. No measured idle hours or no cost data also means no recommendation. For servers that are in use but over-provisioned, see Azure MySQL Flexible Server Burstable Tier Opportunity.

Schedule-based saving on compute only

monthly saving = server monthly cost x measured idle fraction

Storage and backup storage keep billing while the server is stopped, so the real reduction applies to compute hours.

Putting the server on a stop and start schedule

1. Confirm no application, job or replica depends on the server during the idle window.
2. Review the suggested schedule in the recommendation.
3. Apply it, or script it with az mysql flexible-server stop --resource-group my-rg --name my-server in the evening and az mysql flexible-server start in the morning.
4. If the server is not needed at all, export the data and delete it instead.