# Databricks Idle Clusters: How to Find and Fix Them > Databricks idle clusters bill for compute that does little or no work. What counts as idle, how to find it in system tables, and how LakeSentry automates it. - Canonical: https://lakesentry.io/blog/databricks-idle-resources/ - Published: 2026-07-29 - Author: Boris Vasilev --- ## What Counts as Idle in Databricks Databricks idle clusters are compute resources that keep running, and billing, while doing little or no useful work. It could be an interactive cluster left on after a demo or a SQL warehouse that keeps waking on stray queries. The definition of "idle" differs by compute type. An interactive (all-purpose) cluster bills for every hour it stays up, whether anyone is attached or not. A job cluster terminates when its run ends, so its idle risk is small. A SQL warehouse sits in-between the two: it auto-stops after an inactivity window, but a long window plus sporadic queries keeps it warm most of the day. In the UI, SQL warehouses **cannot** be set to never stop: Pro and Classic warehouses enforce a minimum auto-stop of 10 minutes, and serverless allows 5 ([warehouse settings](https://docs.databricks.com/aws/en/compute/sql-warehouse/create)). The API lowers that floor for serverless warehouses, down to 1 minute, but there is no documented way to switch auto-stop off entirely. All-purpose clusters can run forever from either path: `autotermination_minutes` set to `0` disables auto-termination ([cluster settings](https://docs.databricks.com/aws/en/compute/clusters-manage)). So a "forgotten warehouse" usually means a long auto-stop window, while a "forgotten cluster" is one with no auto-termination. > Idle compute doesn't look wrong in the console. It looks exactly like compute that's busy. A cluster at 5% utilization isn't technically idle but it isn't doing useful work either. The console shows current state, not the pattern over time, which is why idle compute is easy to miss (see [what native cost tools show and what they don't](/blog/native-databricks-cost-tools/)). ## How to Find Idle Clusters with System Tables Idle clusters surface when you compare what a cluster was billed for against what it did. `system.billing.usage` records DBU consumption per cluster over time, and high billed hours with low DBUs per hour is the signature of an idle cluster. For more details, `system.compute.node_timeline` has per-node CPU and memory percentages, so you can confirm whether a cluster was running near zero CPU.

Warehouses need a different question answered: when did anyone last run a query against this one? The `system.query.history` table records every statement a warehouse executes. Pair the result with an auto-stop audit, because a warehouse with a 60-minute auto-stop and a query every 50 minutes effectively runs all day. The same tables catch orphaned compute: `system.compute.clusters` names each cluster's owner, and anything owned by a deactivated account has to be highlighted. Writing these queries is an afternoon of work, and for a one-off audit that's all you need. The operational part is what doesn't stick. The results are point-in-time snapshots, the idle thresholds need tuning per environment, and someone has to own running the checks, chasing owners, and repeating the whole exercise next quarter — which is the exact job nobody had when the compute went idle in the first place. ## How LakeSentry Detects Idle Clusters LakeSentry runs this analysis continuously, across every connected workspace. Our idle-cluster detection logic reads the same signals the checks above approximate, node-timeline utilization and runtime windows, and flags clusters that ran with little or no useful activity. The idle-warehouse detector does the equivalent for SQL warehouses, from warehouse events and query activity. Detection is deliberately conservative. Detectors wait for enough recent observations before flagging anything, so a cluster isn't marked idle off one quiet afternoon. Each finding comes with supporting evidence and a cost estimate derived from idle hours and the recent cost rate. Acting on a finding stays under your control: every optimization action requires explicit approval before it executes. LakeSentry provides the context behind each finding: utilization, cost, owner, and the patterns that keep clusters idle, such as long auto-termination settings, scheduled jobs parked on interactive clusters, workers overprovisioned against their observed CPU and memory. ## How to Clean Up Idle Clusters Safely Clean up in stages. Tag the resource, notify the owner, set a sensible auto-termination window, and remove it only after the owner confirms; avoid mass shutdowns. Prevention is policy work. [Compute policies](https://docs.databricks.com/aws/en/admin/clusters/policy-definition) can enforce a maximum or default `autotermination_minutes`, so new clusters inherit a sane idle limit. Set warehouse auto-stop to the shortest window the workload tolerates. For where idle compute sits among the other cost drivers, see [Databricks cost optimization](/blog/databricks-cost-optimization/), and for why scheduled work belongs on cheaper compute, see [all-purpose vs jobs compute](/blog/databricks-all-purpose-vs-jobs-compute/). Idle resources aren't a one-time cleanup — new ones appear constantly as people spin up compute and move on. That ongoing watch is the part LakeSentry takes over. ## FAQ **1. Can a Databricks SQL warehouse be set to never auto-stop?** No. Pro and Classic warehouses enforce a 10-minute minimum auto-stop, and serverless allows 5 minutes in the UI. The API lowers the serverless floor to 1 minute, but has no documented way to disable auto-stop entirely. All-purpose clusters are different: setting the inactivity timeout to zero does disable auto-termination. **2. How do I find idle clusters from system tables?** Compare billed hours in `system.billing.usage` against activity. High billed hours with low DBUs per hour flags an underused cluster; `system.compute.node_timeline` confirms it with per-node CPU and memory percentages. **3. How do I tell if a SQL warehouse is unused?** Query `system.query.history` for the most recent statement per warehouse. A warehouse with no query in days is a cleanup candidate, especially when its auto-stop window is long. **4. What's an orphaned cluster?** A cluster whose owner has left or been deactivated, so nobody is responsible for stopping it. Cross-reference cluster owners in `system.compute.clusters` against your active users to find them. **5. How does LakeSentry detect idle clusters?** LakeSentry continuously analyzes node-timeline utilization and runtime windows across every connected workspace and flags clusters that ran with little or no useful activity, with evidence and a cost estimate attached. SQL warehouses get the same treatment based on warehouse events and query activity. Detectors wait for enough observations to avoid false positives. **6. Should I just delete idle clusters automatically?** Not as a first step. Tag and notify the owner, set auto-termination, and delete only after confirmation. Mass shutdowns without warnings break active work and might erode trust over time.