General Purpose vCore Azure SQL databases with long idle stretches that could auto-pause on serverless
What does ZopNight detect here?
ZopNight flags a provisioned General Purpose vCore Azure SQL Database (a `GP_` service objective) when its CPU averages under 10% over 30 days, or its name marks it as dev or test and CPU data is missing. The saving is the compute share of its bill multiplied by the idle hours ZopNight measured, which serverless auto-pause would stop charging for.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1335 |
| Category | schedule |
| Severity | medium |
| Metric | CPU percentage |
| Threshold | avg CPU < 10% on a provisioned GP_ database |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | Microsoft.Sql/servers/databases/read · Microsoft.Insights/Metrics/Read |
Where it applies
Provisioned compute billed through hours with no queries
A provisioned vCore database pays for its vCores every hour. The serverless tier overview describes the alternative for single databases: compute scales with demand and is billed per second, and after a configurable auto-pause delay of inactivity the database pauses. While paused the compute cost is zero and only storage is billed. Microsoft notes auto-pause and auto-resume are supported only in the General Purpose tier.
Development, reporting and internal-tool databases often go silent every night and weekend. On provisioned compute those hours cost the same as a busy Monday morning.
Finding General Purpose databases with low CPU
az sql db list --resource-group my-rg --server my-server \ --query "[?starts_with(currentServiceObjectiveName, 'GP_')].{name:name, objective:currentServiceObjectiveName}" \ -o table
az monitor metrics list --resource <database-resource-id> \ --metric cpu_percent --aggregation Average Maximum --interval PT1H --offset 30dService objectives with GP_S_ in the name are already serverless.
What qualifies a database for serverless
- The service objective is a General Purpose vCore one starting with
GP_. DTU tiers (Basic, Standard, Premium) and system databases are excluded, and an unknown objective is not assumed. - The database is not already serverless and is not paused.
- Either CPU percentage averages below 10% over 30 days, or, when no CPU data is available, the name marks it as dev, test, qa, staging, sandbox or demo.
- ZopNight has measured idle hours for the database in its weekly activity heatmap, and the database has a monthly cost.
Databases kept on provisioned compute
Business Critical and Hyperscale databases are outside scope, because auto-pause is a General Purpose feature. Without measured idle time or cost data there is no recommendation; ZopNight does not assume a flat share of the bill.
Pausing compute, not storage
monthly saving = database monthly cost x 0.70 x measured idle fractionStorage keeps billing while a serverless database is paused, so only the compute part of the bill can shrink. ZopNight treats 70% of the provisioned bill as compute, an assumed split rather than a measured one, and applies the idle fraction to that share. The recommendation carries the heatmap and a suggested schedule so you can see which hours drive the figure.
Switching the database to serverless
- Check that the application retries connections, since the first login after a pause waits for the database to resume.
- Choose an auto-pause delay; Microsoft’s minimum is 15 minutes.
- Change the compute model:
az sql db update --resource-group my-rg --server my-server --name my-db --compute-model Serverless --auto-pause-delay 60. - Watch the database’s paused hours and billed vCore seconds over the next billing period.