PostgreSQL flexible servers with no connections and no CPU work, where stop is not the answer
What does ZopNight detect here?
ZopNight flags a PostgreSQL flexible server when active connections and CPU both stay under a floor of 1 on both average and peak for 30 covered days, then recommends deletion rather than stop: a stopped flexible server auto-restarts after 7 days and keeps billing provisioned storage the whole time.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1340 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | postgres_idle.go |
Where it applies
Connections alone cannot prove a database is dead
A background job, replication, or autovacuum can burn CPU without holding a client connection
the gauge would count, and a short-lived connection can slip between gauge samples. So this
rule reads two Azure Monitor series and requires both silent: active_connections below 1 and
cpu_percent below 1 percent, on both the average and the maximum, across a 30-day window with
full coverage on each series. A single busy hour on either axis vetoes the finding.
The 7-day boomerang that makes stopping useless
The natural instinct for an idle database is to stop it. On a flexible server that instinct fails twice: Azure automatically restarts a stopped flexible server after 7 days, and the provisioned storage bills at full rate the entire time it is stopped. A stop is a nap, not a saving. That is why this finding recommends deletion, after a backup, as the only durable lever, and why ZopNight prices the saving as the full compute-plus-storage run-rate.
Look at both axes in one query
az monitor metrics list \ --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforPostgreSQL/flexibleServers/<name>" \ --metric active_connections cpu_percent \ --interval PT1H --offset 30d --aggregation Average MaximumWhat holds the rule back
Either metric series missing, under 30 days of coverage on either, any hour at or above either floor, or an unpriced cost: all abstain. There is deliberately no tag fallback: no customer-controlled label can authorize stopping or deleting a database. The floors exist because a live-but-idle server still registers monitoring-agent and autovacuum noise; exact zero would never trigger.
An exit that keeps the data
Take a final backup before acting. Use pg_dump for portability, or rely on the server’s
point-in-time restore window for a grace period. Then delete the server, which ends both the
vCore compute charge and the storage charge. If you only suspect the server is dormant, drop
the compute tier to Burstable first and watch the connection metric for a month.
Access needed to run this check
Reader covers the discovery and the server properties; Monitoring Reader covers both metric series. ZopNight’s write role can stop and start flexible servers for scheduling, but this finding’s remediation is deletion, and that is always a human decision.