Azure SQL databases idling below 10% DTU with a named tier to drop to
What does ZopNight detect here?
ZopNight flags an online Azure SQL database when 30-day average DTU consumption sits under 10%, the peak never touched the 80% ceiling, and a concrete one-step-down service objective exists (S3 to S2, for instance). Savings come from the real DTU-tier rate delta; vCore and bottom-rung databases abstain.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-230 |
| Category | rightsizing |
| Severity | high |
| Metric | none — pure configuration read |
| Source | sql_rightsizing.go |
Where it applies
DTU tiers make overprovisioning invisible
A DTU-model database bills its service objective flat: an S3 costs the same at 2% consumption as at 90%. Because scaling is a slider someone set once, databases routinely run years above their need. The rule reads the DTU-consumption series over 30 days; an average under 10% marks the database as provisioned for a workload it does not have. Only databases in an online state are considered; restoring, offline, and paused databases are skipped.
The nightly-spike safeguard
Low average with a violent peak is common in databases: quiet all day, then an ETL job that saturates the tier at 3 a.m. Downsizing that database trades money for timeouts. When the trusted peak of the full series reaches 80%, the recommendation is suppressed regardless of the average. The headroom is real, just rarely used. A CPU series, when present, is attached as corroborating evidence.
One named step down, priced for real
The recommendation always names its target: the next objective down the DTU ladder in the same tier: S3 to S2, P2 to P1. The dollar figure is the actual rate difference between those two objectives in your region. Three cases abstain by design: vCore-model databases (no DTU ladder to walk), bottom-rung objectives like S0, P1, and Basic (nowhere to go), and missing rate data (nothing honest to print).
Read your own DTU curve
az monitor metrics list \ --resource "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Sql/servers/<srv>/databases/<db>" \ --metric dtu_consumption_percent \ --interval PT1H --offset 30d --aggregation Average MaximumScaling down is an online operation
A service-objective change on Azure SQL is a hot resize, with no stop, no data movement you manage, and a brief connection blip at cutover. Scale one step, hold for a billing cycle, and check Query Performance Insight for regressions before considering another. Elastic-pool databases have the analogous lever in eDTU reduction on the pool.
Rule inputs and access
Reader, Monitoring Reader, and Cost Management Reader reproduce everything the rule sees. High severity reflects how often DTU databases are set-and-forgotten several sizes too large.