Skip to main content
schedule · databricks

SQL warehouses with auto-stop off, billing through every idle stretch

resource types
1
rule IDs covered
3
severity
medium

What does ZopNight detect here?

Auto-stop set to 0 minutes on a classic SQL warehouse means the full cluster rate bills through every idle gap between queries. ZopNight attaches a dollar figure only when a measured idle percentage exists for that specific warehouse; serverless warehouses draw a softer, low-severity nudge since they suspend natively.

Signal and threshold

How ZopNight evaluates SQL warehouses with auto-stop off, billing through every idle stretch.
Field Value
Rule IDsRC-2303 · RC-2403 · RC-2203
Categoryschedule
Severitymedium
Metricnone — pure configuration read
Sourcewarehouse_autostop.go

Idle billing is the classic warehouse’s failure mode

A classic or PRO SQL warehouse is a cluster that stays up between queries, and it bills at its full rate while waiting. Auto-stop is the entire cost model: with it, a quiet afternoon costs minutes of compute; without it, the warehouse bills the whole afternoon, the night, and the weekend. The rule’s detection line for classic warehouses is auto-stop disabled entirely (the auto_stop_mins field at 0) or set above the 60-minute ceiling that separates a deliberate idle window from an effectively unbounded one.

Serverless gets a different yardstick

Serverless SQL warehouses suspend natively and bill per second of activity, so a generous auto-stop value is not the exposure it is on classic compute. ZopNight therefore suppresses the excessive-value branch entirely for serverless and flags only the fully disabled case, at low severity: a nudge that keeping a warm endpoint costs something, not an alarm. A warehouse whose serverless flag is absent from older inventory is treated as classic, the safe default.

Where the dollar figure comes from, and when it will not

A cost finding here carries real money only when two inputs exist for the specific warehouse: its priced monthly cost, and a measured idle percentage derived from usage heatmaps. The savings claim is cost times measured idle share, and it is only made for the auto-stop-disabled case, where the whole idle window genuinely bills. For an enabled-but-excessive setting the existing auto-stop already reclaims the long gaps, so that formula would double-count, so the rule abstains on that branch rather than over-claim. One more honesty note: the per-warehouse idle series is not yet produced by the aggregator, so in practice today the rule detects the configuration gap but abstains from dollar claims until that producer lands.

Find the disabled warehouses

Terminal window
databricks api get /api/2.0/sql/warehouses | jq '
.warehouses[]
| select(.auto_stop_mins == 0)
| {name, size, enable_serverless_compute}'

Setting a window that fits the workload

Sixty minutes is the ceiling, not the target. BI warehouses serving business-hours dashboards do well at 15 to 30 minutes; dev and ad-hoc warehouses at 10. The restart cost is a short warm-up on the next query; weigh it once, then let auto-stop do the arithmetic every idle evening after.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

417 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

417 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·