Azure Database for MySQL Flexible Server
Does ZopNight manage 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.
Rules that fire on Azure Database for MySQL Flexible Server
At a glance
| Field | Value |
|---|---|
| Scheduling notes | stopped and started via the Flexible Server API, but only when the server is in the Ready state. |
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.