Databricks SQL warehouses running with auto-stop turned off
What does ZopNight detect here?
ZopNight checks running Databricks SQL warehouses whose `auto_stop_mins` is 0, meaning auto-stop is off, and would price the saving as monthly cost times the measured idle share. That idle share is not measured yet, so no finding is raised today. Warehouses set above 60 minutes are judged too loose but also get no finding.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-2303 · RC-2403 · RC-2203 |
| Category | schedule |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | auto_stop_mins = 0 |
| Source | ZopNight |
| Permissions used | GET /api/2.0/sql/warehouses |
Where it applies
A running warehouse meters whether or not anyone queries it
SQL warehouses bill while they are up. Databricks’ warehouse configuration page states that idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped, which is what the auto-stop setting is for. Its recommended defaults differ by type: 10 minutes for serverless warehouses, with a 5-minute minimum in the UI, and 45 minutes for pro and classic warehouses, with a 10-minute minimum.
Through the Warehouses API,
auto_stop_mins of 0 means no auto-stop at all, and the API default is 120 minutes, well above
what the UI suggests. Warehouses created by script or infrastructure code often end up on that
longer value without anyone choosing it.
Listing warehouse stop settings
databricks warehouses list -o json \ | jq -r '.[] | [.id, .name, .state, .warehouse_type, (.enable_serverless_compute|tostring), .auto_stop_mins] | @tsv'Tighten one with databricks warehouses edit <id> --auto-stop-mins 10.
The limits ZopNight applies by warehouse type
- Classic and pro warehouses are judged against a 60-minute ceiling:
0(off) and anything above 60 fail it, and exactly 60 is acceptable. Only the0case becomes a finding (see below). - Serverless warehouses get more room: ZopNight accepts a long auto-stop on them and judges them only on auto-stop being off, reported at low severity.
- A warehouse with no serverless value recorded is treated as classic.
- Stopped warehouses and those in error are skipped, and a warehouse with no recorded auto-stop value is not judged.
Where a dollar figure is and is not shown
The saving is calculated only for warehouses with auto-stop turned off, and only when ZopNight has a monthly price for the warehouse and a measured share of the week it sits idle. ZopNight does not yet measure that idle share for SQL warehouses, so today no finding is raised, even with auto-stop off. For warehouses whose auto-stop is on but set above 60 minutes, the current setting already recovers the long idle gaps, and the extra waste depends on how long each gap runs, which ZopNight does not measure. Rather than overstate it, no finding is raised for that case. Use the CLI listing above to catch those warehouses.
Idle share times monthly cost
saving = warehouse monthly cost x idle share of the weekcost after fix = monthly cost - savingOnce the idle share is measured, findings will carry the idle heatmap and a suggested schedule, so you can see which hours are wasted.
Tightening auto-stop
- For production BI warehouses, set auto-stop to 60 minutes or less; the 45-minute default for pro and classic is a reasonable start.
- For development and ad hoc warehouses, go shorter, down to the 10-minute minimum.
- Leave serverless warehouses near their 10-minute default and never at 0.
- Warehouses nobody queries at all belong to Orphaned SQL Warehouse; stop or remove them instead of tuning them.