SQL warehouses that served zero queries in 30 days
What does ZopNight detect here?
Query count of exactly 0 across 30 days is the sole trigger here: a warehouse nobody queries is clutter whether currently running or stopped, so there is deliberately no power-state filter. ZopNight abstains when the count is absent rather than guess, and attaches no dollar figure.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-2331 · RC-2431 · RC-2231 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Source | orphan_warehouse.go |
Where it applies
Usage decides, not power state
Most of ZopNight’s Databricks rules skip stopped resources, since stopped compute is not current spend. This one deliberately does not: “nobody has queried this warehouse in a month” is equally true and equally worth knowing whether the warehouse is currently stopped or, worse, sitting in a running state on a loose auto-stop. That design choice cuts both ways, and the finding says so: a flagged warehouse may be actively billing right now, which makes it more urgent, not less accurate.
One counter, read strictly
The discoverer stamps a 30-day query count onto each SQL warehouse; the rule fires only when that count is present and exactly 0. An absent counter (older inventory collected before the field existed) produces no finding, because “we did not measure” and “nobody queried it” are different statements. No DBU quantity is available to price the cleanup, so the savings figure is deliberately 0: this is an orphan-hygiene call, and its dollar consequences depend on what the auto-stop configuration was doing, which the sibling auto-stop rule prices separately.
Reproduce it from query history
databricks api get '/api/2.0/sql/history/queries?filter_by.warehouse_ids=abc123def456&max_results=10' | jq '.res | length'A result of 0 for a warehouse ID over your chosen window is the raw form of this finding.
An age guard that is wired but empty
The rule mirrors its orphan-job sibling with a 30-day minimum-age guard, so a warehouse provisioned ahead of a launch is spared. But the SQL warehouse API does not currently expose a creation timestamp, so the guard has nothing to read and is a no-op today. Practical consequence, stated honestly: a freshly created, not-yet-used warehouse can appear in this finding. If you know the warehouse is pre-launch infrastructure, dismiss the finding; the guard will start protecting such cases automatically once a creation-time producer exists.
Decommission in the safe order
Repoint first: dashboards, BI connections, and saved queries referencing the warehouse should move to an active one before anything is turned off. Then stop the warehouse and tighten its auto-stop as a reversible middle state, and delete only after a quiet period confirms nothing broke. Deleting first and discovering the dependent dashboard second is the failure mode this ordering exists to prevent.