# Stop idle ClickHouse Cloud dev services every weeknight

> Every weeknight, find the dev, test and staging databases nobody is using, switch them off, and log the savings to Slack and a spreadsheet.

- Workflow type: agent
- Services: ClickHouse Cloud, Slack Bot, Google Sheets
- Categories: Engineering, Finance
- Published: 2026-08-14

## What it does

- Checks every service in your ClickHouse Cloud account each weeknight evening, along with what each one actually cost you over the past week
- Switches off the non-production ones (dev, test, staging, sandbox, qa) that are still running but barely being used
- Leaves anything marked production alone, plus anything still receiving live incoming data, and tells you why each one was skipped
- Posts a nightly recap to your engineering Slack channel and adds every shutdown to a savings spreadsheet with a running total

## What you'll need

- A ClickHouse Cloud account with permission to start and stop services
- Names or labels on your services that make clear which ones are production and which are not
- A Slack workspace and a channel for the nightly recap
- A Google account and a spreadsheet to use as your savings ledger

## Prompt

Every weeknight at 8pm, sweep my ClickHouse Cloud organization for non-production services that are sitting idle and burning money, and shut them down.

Start by calling List Organizations to discover my organization id, since the rest of the ClickHouse Cloud calls are nested under it. Then call List Services to pull every service in the organization, and Get Service on each one to read its current state, its tags, and its scaling and auto-pause settings. Also call Get Organization Usage Costs for the last seven days, passing from_date and to_date in YYYY-MM-DD form, so you can see what each service actually cost me over that window. Responses come back wrapped in a status, requestId and result envelope, so read the payload from result. Pace the per-service calls, because each API key is capped at ten requests per ten seconds.

Treat a service as a shutdown candidate only when all of these are true: its name or one of its tags matches dev, test, staging, sandbox or qa; it is currently running; and its usage cost over the last seven days is negligible.

Be conservative about what you touch. Never stop a service whose name or tags contain production or prod, even if it also matches one of the non-production patterns. Never stop a service that has an active ingestion pipeline feeding it: call List ClickPipes for each candidate and leave the service running if any pipe is in a running or active state. If a service already has aggressive auto-pause or idle scaling configured, leave it running as well and simply report it, since it will pause itself.

For each service that survives all of those checks, call Update Service State with the stop command. Stopping is asynchronous, so the service will report a stopping state immediately after the call and settle shortly after. Do not block waiting for it. This is low risk because ClickHouse Cloud services wake automatically when a client connects, so a developer who runs a query the next morning just resumes the service.

When the sweep is finished, post one message with Slack Bot to my engineering channel. List every service that was stopped along with its cost over the last seven days, then list every non-production service that was deliberately left running with the reason for each one (tagged production, active ingestion pipe, already auto-pausing, or cost was not negligible), and close with the estimated monthly saving from everything that was stopped. Post the message even on nights when nothing was stopped, so I know the sweep ran.

Then append one row per stopped service to my Google Sheets savings ledger using Append Values, with today's date, the service name, its cost over the last seven days, and a running total. Read the existing ledger rows first with Get Values so the running total continues from the last row rather than restarting from zero.

## How to customize

- Change the schedule: run it every weeknight, only on Friday evenings, or at a different hour
- Adjust which names and labels count as non-production, and how low a service's weekly cost has to be before it counts as idle
- Send the recap to a different channel or as a direct message, or skip the spreadsheet ledger entirely

## FAQ

### What happens if someone needs one of these services the next morning?

ClickHouse Cloud services wake back up automatically when someone connects to them, so a developer who runs a query simply resumes the service. Nothing is deleted and no data is lost, you just stop paying for the hours nobody was using it.

### Could this accidentally shut down our production database?

No. Anything named or labeled production or prod is excluded, even if it also matches one of the non-production patterns. Services that are still receiving live incoming data are also left running, and every skipped service is named in the recap so nothing is quietly turned off.

### How do I know what it did each night?

Every run posts a single Slack message listing what was stopped, what was deliberately left running and the reason for each, and the estimated monthly saving. It posts even on nights when nothing needed stopping, so you always know the sweep ran.

### Isn't this the same as the spend alerts ClickHouse Cloud already has?

Not quite. The built-in alerts email you when your total spend crosses a percentage of your budget. They do not break the cost down service by service and they never turn anything off. This one attributes cost per service and takes the action for you.

### Will it stop services that are already set to pause themselves?

No. If a service already pauses itself when idle, it gets mentioned in the recap and left alone, because it is already handling its own costs.

Use this prompt in General Input: https://www.generalinput.com/prompts/stop-idle-clickhouse-cloud-dev-services-every-weeknight