Shutting down dev and staging Kubernetes clusters at night: a 65 percent cut

Quick answer

A development cluster running 24x7 bills 730 hours per month. Used only on weekdays from 8am to 8pm, it is genuinely needed for about 260 hours, so 64 percent of its node cost is waste. Scaling node pools to zero outside those windows on a 20-node dev cluster at $5,600 per month saves roughly $3,600. The control plane fee, about $73, keeps billing since you cannot pause it, and load balancers keep billing unless the Services are deleted. Use a scheduled scaler on node group min and max sizes, keep one small always-on node for CI webhooks, and make wake-up self-service so nobody is blocked.

There is no argument against this one. Nobody claims the staging cluster needs to run at 3am on Sunday. Yet most organizations pay for exactly that, because turning things off requires a small amount of automation and nobody owns it.

The hours arithmetic

Schedule	Hours per month	Share of 24x7	Cost on a $5,600 cluster
Always on	730	100 percent	$5,600
Weekdays 7am to 8pm	283	39 percent	$2,170
Weekdays 8am to 7pm	239	33 percent	$1,833
Weekdays 9am to 6pm	196	27 percent	$1,503

A generous 7am to 8pm weekday window already cuts 61 percent. Tightening it further has diminishing returns and raises the chance of blocking someone, so most teams land on 12 to 13 hours on weekdays and full shutdown at weekends.

What actually stops billing

This is where teams get disappointed. Scaling workloads to zero replicas does not save anything by itself, because the nodes are still running. You have to remove the nodes.

Component	Stops billing when scaled to zero?
Worker nodes	Yes, this is the whole saving
Control plane fee	No, charged while the cluster exists
Load balancers	No, unless the Service is deleted
Persistent volumes	No, disks bill while provisioned
NAT gateway hourly fee	No, unless destroyed
Container registry storage	No

So a $5,600 dev cluster does not go to $0. It goes to roughly its fixed floor: $73 control plane, maybe $90 of load balancers, $200 of persistent volumes, $33 of NAT gateway. Call it $400. Running 33 percent of the hours takes the node line from $5,600 to $1,833, and the total from about $6,000 to $2,233, a 63 percent cut.

How to implement it

The mechanism that works is setting node group min, max, and desired size on a schedule rather than deleting anything. A CronJob inside the cluster, or a scheduled pipeline, patches the node group to min 0 max 0 at 8pm and back to min 2 max 20 at 7am. Nothing about the cluster's identity, DNS, storage, or configuration changes, so wake-up is fast and safe.

Two practical details. First, scale workloads down before the nodes go, or the autoscaler will fight you because pending pods keep requesting capacity. A common pattern is annotating Deployments with their normal replica count, scaling them to zero, then zeroing the node group. Second, keep one small always-on node, a t-class or e2-small, for the CI webhook receiver and the wake-up controller itself, roughly $15 per month well spent.

Make wake-up self-service

The single reason these schedules get disabled is someone needing the cluster at 9pm and having no way to get it. Provide a one-command or one-click wake-up: a chat command, a pipeline button, or a small web hook that patches the node group back up. Add an auto-sleep timer of 2 hours after a manual wake so the override does not become permanent by accident.

Also publish the schedule. Most friction comes from surprise, not from the policy. A calendar entry and a banner in the dev environment removes almost all complaints.

Time zones deserve a sentence of their own. A schedule written in UTC that works perfectly for a team in Berlin will shut the cluster down mid-afternoon for a team in San Francisco. If engineers are spread across regions, either widen the window to cover both working days, which still saves 40 to 50 percent, or run separate non-production clusters per region with local schedules. Getting this wrong once is usually enough for a team to demand the schedule be removed entirely, which costs far more than the wider window would have.

Beyond the schedule

Action	Additional saving
Spot nodes for all non-production	60 to 70 percent of remaining node cost
Smaller instance types in dev	20 to 40 percent
One shared ingress instead of per-service load balancers	$300 to $500 per month
Delete ephemeral preview environments after 3 days	Varies, often the largest line

Stacking a schedule with spot nodes is the big one: 33 percent of the hours at 35 percent of the rate is roughly 12 percent of the original node cost. Non-production is the ideal place for spot because an interruption at 2pm on a Tuesday is an inconvenience, not an incident. See thespot nodes guide for the setup, andidle cluster cost for what else keeps billing.

Node group schedules and sizes are Terraform-managed, so the savings are priceable before they are real. Price the dev fleet against the resource catalog at both its awake and asleep sizes and the business case writes itself.

FAQ

How much does shutting down dev Kubernetes clusters at night save?

About 60 to 65 percent of the total cluster bill. A dev cluster running 24x7 bills 730 hours per month but is genuinely needed for roughly 239 hours on a weekday 8am to 7pm schedule. On a $5,600 per month node bill that takes nodes to $1,833, and total cluster cost from about $6,000 to $2,233 once the fixed floor is included.

Does scaling Kubernetes workloads to zero save money?

Not by itself. Setting Deployments to zero replicas leaves the nodes running, and nodes are what the cloud bills for. The saving comes from scaling node groups to zero, which means scaling workloads down first so pending pods do not keep the autoscaler provisioning capacity, then patching the node group min and max to zero.

What keeps billing when a Kubernetes cluster is scaled to zero?

The control plane fee of about $73 per month, any load balancers created by Services since those persist unless the Service is deleted, persistent volumes which bill on provisioned capacity regardless of pods, NAT gateway hourly fees, and container registry storage. A typical dev cluster floor is around $400 per month even with zero nodes.

How do I schedule Kubernetes cluster shutdown?

Patch node group min, max, and desired size on a schedule rather than deleting anything. A CronJob or scheduled pipeline sets min 0 and max 0 at the end of the working day and restores min 2 max 20 in the morning. Keep one small always-on node for the CI webhook receiver and the wake-up controller, roughly $15 per month.

What if someone needs the dev cluster outside working hours?

Make wake-up self-service, through a chat command, a pipeline button, or a webhook that patches the node group back up, and add an auto-sleep timer of about two hours after a manual wake so the override does not become permanent. The main reason shutdown schedules get disabled is someone being blocked with no way to restore capacity.

How does C3X help justify non-production shutdown schedules?

Node group sizes and schedules are Terraform-managed, so C3X can price the dev fleet against a live catalog at both its awake and asleep sizes. That turns the shutdown proposal into two concrete monthly numbers in a pull request, which is a far easier business case than an estimate, and it verifies the saving after the change lands.

What to do next

Price the awake and asleep cluster side by side. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.