# Scheduling Azure Database for MySQL Flexible Server

> Azure stops a MySQL Flexible Server only from the Ready state and starts any stopped server automatically after 30 days, a far longer leash than the 7-day databases. Compute halts while storage and backup meters continue, and servers in replication topologies refuse the stop entirely.

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

---

## Thirty days of leash

MySQL Flexible Server allows the longest stop on the Azure database shelf: a stopped server
stays stopped for up to 30 days before the platform restarts it. Nightly and weekend schedules
never approach the limit, but the month-long window also makes this one of the few databases
where "stop it until the project resumes" is nearly practical, provided somebody diaries the
restart for day 30.

## Ready or skipped

The stop is attempted only against a server in the Ready state. A server mid-backup,
mid-maintenance or otherwise busy at the stop hour is left alone. That is a soft skip, not a forced
shutdown, which trades a night of savings for never corrupting an in-flight operation. If the
skip happens repeatedly, the nightly maintenance and backup windows are colliding with the
stop cron; move one of them.

## Replication takes stop off the table

Servers wired into replication (a source with read replicas, or a replica itself) cannot be
stopped. The topology has to come apart first, which is rarely worth it in production but
highlights the real audience for this schedule: standalone dev, test and staging servers,
which are also exactly the ones idling 118 hours a week.

## The meters that keep spinning

Stopping halts compute billing. Provisioned storage bills at its full size, and backup storage
beyond the free allowance bills too. A stopped server with a large provisioned disk keeps a
real monthly floor, so quote the saving as the compute SKU's hours, not the server's whole
line.

## The morning buffer pool is empty

First connections after start find cold caches, and query latency takes a while to settle to
its usual shape. Start the server ahead of the first application connection, and expect the
connection pool to churn once as stale sockets are replaced.

A synthetic health check that connects immediately after the start cron absorbs that churn before
any person or pipeline meets it.