MySQL Flexible Servers with zero active connections for a month
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-243 |
| Category | schedule |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | flexserver_idle.go |
Where it applies
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
az monitor metrics list --resource <flexible-server-id> \ --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.