# Azure Database for MySQL Flexible Server

> MySQL Flexible Server compute billing pauses when the server is stopped through the Flexible Server API, and Azure force-restarts any stopped server after 30 days. ZopNight stops non-production servers on schedule from the Ready state, tracks 60 days of Azure Monitor utilization, and keeps counting storage, which bills throughout.

Source: https://zop.dev/integrations/azure/mysql-flexible
Updated: 2026-08-19

---

MySQL Flexible Server is the current managed MySQL offering with zone redundancy and native stop/start support. Because compute billing pauses while stopped, it is one of the highest-value database types to schedule.

## Compute pauses on stop; storage never does

A Flexible Server bills separately for compute (its vCore tier), provisioned storage, and backup retention. Stopping the server suspends the compute meter (the dominant line for most non-production servers) while provisioned storage and backups continue at their normal rate. The result is that a stopped server is cheap but not free, and a server with a large disk retains a meaningful floor cost that no schedule can remove.

## The 30-day automatic restart

Azure automatically restarts a stopped Flexible Server after 30 days. A server "parked" indefinitely will quietly come back online and resume full compute billing on day 31. A recurring schedule sidesteps this entirely, since the server never stays stopped long enough to trigger the restart. Anyone relying on a one-off manual stop should know the clock is running.

## Scheduling MySQL Flexible Server with ZopNight

Discovered via Azure Resource Graph. Azure Monitor metrics (60-day lookback) track utilization, Cost Management billing attributes spend, recommendations cover rightsizing and reservations, and schedules stop it outside working hours. ML auto-tagging covers this type. One operational nuance from the frontmatter above: the stop and start calls succeed only when the server is in the Ready state, so ZopNight will not fire against a server mid-maintenance or mid-failover.

## Where MySQL Flexible Server wastes money

The classic patterns: staging databases running every hour of the week for a working window a quarter that size; vCore tiers chosen defensively at creation and never revisited despite months of low utilization; and reserved capacity purchased for servers that later moved onto stop/start schedules, where a reservation bills whether or not the server runs.

## Checking server state in the Azure portal

Azure portal → Azure Database for MySQL servers → select the server: the Overview blade shows Status (Ready or Stopped) along with the Stop and Start buttons, mirroring exactly what a ZopNight schedule performs via the API.