# Schedule Databricks Clusters on GCP: Cut Idle Cost > ZopNight schedules Databricks Clusters on GCP to run on your team's hours and stop the rest of the time. Read-only setup, dependency-aware, production excluded by default. Source: https://zop.dev/zopnight/gcp/databricks-clusters Published: 2026-07-01 · Author: avinash-gaurav · Tags: zopnight, gcp, analytics, scheduling --- Most of what teams spend on Databricks Clusters in non-production is spent while nobody is watching. In a development, staging, or QA account these resources are billed for every hour they exist, but the people who use them work a fraction of those hours. Nights, weekends, holidays, and the long tail of "we'll get back to that environment next sprint" all meter at full price. ZopNight closes that gap by scheduling your Databricks Clusters to run on your team's hours and stop the rest of the time, without touching your data and without a migration. It is the most direct lever in [FinOps](https://zop.dev/learn/finops), and for teams comparing tools it is where ZopNight pulls ahead of dashboard-first platforms like [CloudHealth](https://zop.dev/compare/cloudhealth-vs-zopnight). ## Why Databricks Clusters cost more than they should Cloud providers bill Databricks Clusters by the hour whether or not anyone is using them, and most non-production fleets default to running 24/7 out of habit rather than need. At typical on-demand rates ($0.50 to $10.00/hr including DBUs) an always-on instance quietly bills the same on a Tuesday afternoon as it does at 3 AM on a Sunday. Here is the shape of it. Say a box runs at a typical on-demand rate of $0.17 an hour. Left on around the clock that is about $124 a month, because a month is roughly 730 hours. Confine it to a single-shift work week, about 50 hours, and you pay for 50 hours instead of 730. Your own rate and hours will differ, but the ratio is the point: in non-production, most of the meter runs while nobody is working. The instinct is usually to reach for a smaller instance type. But rightsizing only helps a resource that is genuinely too big; it does nothing for a correctly-sized resource that simply runs when no one is around. The larger, easier win is refusing to pay for the hours nobody is working, and it carries none of the performance risk of down-sizing a box that might spike tomorrow. ## Stopping and starting Databricks Clusters safely ZopNight handles the terminate and start via the Databricks Clusters API on every Databricks Clusters in scope, in dependency order so nothing comes up before what it depends on. A scheduled stop preserves your data exactly as a normal power-off would; ZopNight never terminates or deletes the resource, and idle detection watches CPU, network, and disk signals to surface the Databricks Clusters that are running but doing nothing. In practice the setup is: Connect Databricks on GCP as a standalone account with an OAuth M2M service principal; ZopNight recognises the cloud from the workspace host; ZopNight discovers all-purpose and job clusters, pools, and SQL warehouses under the workspace; Define schedules per cluster (for example terminate at 8 PM, start at 8 AM on weekdays); ZopNight terminates the cluster over the workspace service principal and starts it again before working hours. If you run Databricks Clusters you probably also run [Databricks Pools](https://zop.dev/zopnight/gcp/databricks-pools), [Databricks SQL Warehouses](https://zop.dev/zopnight/gcp/databricks-sql-warehouses), and scheduling them together is where the dependency ordering earns its keep. Related reading: [scheduling](https://zop.dev/solutions/scheduling) and [cost optimization](https://zop.dev/solutions/cost-optimization). ## Frequently asked questions ### Does terminating a cluster lose my notebooks? No. Notebooks live in the workspace and are preserved. Spark session state is cleared on terminate, so most engineers re-run their notebooks when the cluster starts. ### How does ZopNight connect to Databricks on GCP? As a standalone connection keyed by the Databricks account ID with an OAuth M2M service principal. No separate GCP cloud account is required; the account console host tells ZopNight the workspace runs on GCP. ### Can ZopNight schedule pools and SQL warehouses too? Yes. Clusters, instance pools, and SQL warehouses are all schedulable on AWS, Azure, and GCP using the same schedules, groups, and overrides.