# Idle Azure MySQL Flexible Server > An Azure MySQL Flexible Server with zero average active connections over 30 days and CPU under 2% is flagged idle by RC-243, which recommends a recurring off-hours stop/start schedule. Azure auto-restarts a stopped server after 30 days, so one-shot stops don't hold. Savings equal cost times the measured idle fraction. Source: https://zop.dev/integrations/azure/recommendations/idle-azure-mysql-flexible-server Updated: 2026-08-19 --- ## Connections are the verdict, CPU is the witness The idle test for a managed database is whether anything talks to it. RC-243 treats the Azure Monitor `MySQLActiveConnections` series as authoritative: the average must be exactly zero across the full collected window. CPU corroborates: an average at or above 2% vetoes the finding. Notably, 2% is deliberately stricter than the 5% idle bar most of ZopNight's fleet uses. A Flexible Server runs its own background threads even when unused, so its noise floor sits higher than a plain VM's; setting the bar lower means the rule can only under-report, never park a live database. Both gates read the entire metric history, so a server active earlier in the window but quiet recently is not flagged. ## Freshly-restored servers get the benefit of the doubt Zero connections is also what a server reports in the hours after a restore, before clients reconnect. The coverage guard requires the connection series to span a minimum number of observed days before a zero is trusted; a thin series abstains. A server that already has a known recurring schedule is skipped too, since it reports zero connections at night *because* it is intentionally parked, which is success, not abandonment. Metrics come via **Monitoring Reader**; when the connection series is absent altogether the rule abstains, since the discoverer never emits a connections tag to fall back on. ## The 30-day boomerang built into Azure Stopping a Flexible Server pauses compute billing, but Azure automatically restarts any stopped Flexible Server after 30 days. A one-shot stop is therefore never a durable fix for recurring idleness; the server comes back and so does the bill. The recommendation is a recurring stop/start schedule, applied through the **Zopnight Write Access** custom role (`Microsoft.DBforMySQL/flexibleServers/start/action` and `stop/action`). Storage and backup charges persist either way; deletion is suggested only if the database is confirmed dead, and only after exporting data. ## Money only from measurement Savings are cost × the heatmap-measured idle fraction produced from this server's own cpu/memory/connections history. With no heatmap data, a zero idle fraction, or missing pricing, the rule returns nothing. There is no assumed fraction and no advisory row. ## See the connection count directly ```bash az monitor metrics list --resource \ --metric active_connections --aggregation Average \ --interval PT1H --offset 30d \ --query "avg(value[0].timeseries[0].data[].average)" ``` A result of 0.0 over the month reproduces the rule's core evidence.