# Azure PostgreSQL Server Idle > 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. Source: https://zop.dev/integrations/azure/recommendations/azure-postgresql-server-idle Updated: 2026-08-19 --- ## 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 ```bash az monitor metrics list \ --resource "/subscriptions//resourceGroups//providers/Microsoft.DBforPostgreSQL/flexibleServers/" \ --metric active_connections cpu_percent \ --interval PT1H --offset 30d --aggregation Average Maximum ``` ## What 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.