# Run your whole ClickHouse Cloud fleet from one screen

> See every database service grouped by environment, with state, size, backups and health, and start or stop them safely without the console.

- Workflow type: app
- Services: ClickHouse Cloud, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-16

## What it does

- Puts every database service from every one of your organizations on a single board, grouped into production, staging and dev.
- Shows each service at a glance: whether it is running, where it lives, how big it is, its connection details, when it was last backed up, and a small live health strip.
- Lets you start, stop or wake a service right from its row, with a confirmation step and a typed service name required before anything marked production can be switched off.
- Keeps a record of who owns each database and what it is for, so anyone opening the app can see who to ask first, and posts a plain-language maintenance heads-up to a Slack channel.

## What you'll need

- A ClickHouse Cloud account, with access that allows managing services rather than only viewing them.
- A Slack workspace, and the channel where maintenance notices should be posted.
- The environment tags you already use on your services, such as production, staging and dev. Services with no tag still show up, in their own group.

## Prompt

I want an app that acts as the control surface for every ClickHouse Cloud database service my team runs, so I stop clicking through the ClickHouse console organization by organization. This is the ClickHouse Cloud management API, which provisions and manages services, backups and keys. It is not the per-service SQL query endpoint, so the app never runs queries against the data.

The main screen is a board of all services. Discover the organizations first with List Organizations, since almost every other path is nested under an organization id, then pull the services for each organization with List Services. Group the rows by environment tag, production, staging and dev, read from each service's tags. Any service without an environment tag goes into its own Untagged group rather than being hidden.

Each row shows the service state, its cloud provider and region, its size or replica sizing, its connection endpoints, the latest backup date from List Service Backups, and a compact live health strip. List Service Backups returns most recent first, so the first entry is the one to display, and a service with no backups should read as No backups rather than blank.

For the health strip, note that Get Service Metrics returns Prometheus text exposition format on text/plain, not the JSON envelope, so the app has to parse the text rather than reading fields. To keep the board cheap, prefer Get Organization Metrics once per organization to fill every row's health strip in a single call, and use Get Service Metrics for the focused view when a single service is open.

Clicking a row opens a detail panel backed by Get Service, showing the full record including connection endpoints, tags, IP access list and backup history.

From the row and the detail panel I can start, stop or wake a service with Update Service State, and edit its name, tags and IP access list with Update Service. Every state change asks for confirmation first. On top of that, anything tagged production cannot be stopped until I type the exact service name into the confirmation box, and the button stays disabled until the typed text matches.

Each service also gets an owner and a purpose note that the app stores itself, keyed by service id, editable from the detail panel and visible on the board row. These are shared by everyone who opens the app, so anyone can see who to ask before touching a database. They are app-side only and are never written back into the service record.

There is also a button that posts a plain-language maintenance heads-up to a chosen Slack channel using the Slack Bot Send a Message operation. Let me pick the channel from a list loaded with the Slack Bot List Channels operation, and prefill the message with the service name, its environment, what is about to happen, who owns it and the expected impact, in ordinary language rather than raw fields, so I can edit before sending.

Bake in that start, stop and wake are asynchronous. The call returns immediately with a transitional state such as starting, stopping or provisioning, so the app must keep refreshing that service with Get Service until the state settles into a resting state like running, stopped or idle. Show an in-progress indicator while it settles and never present the transitional state as final. If it has not settled after a reasonable number of attempts, stop refreshing and tell me it is taking longer than expected instead of spinning forever.

Also bake in the rate limit: each API key allows only 10 requests per 10 second sliding window, and going over returns a 429. Stagger and queue the calls rather than firing one request per service at once, load and refresh the board in small batches so a large fleet arrives in waves, back off and retry when a 429 comes back, and prefer organization-level calls wherever one call can cover many services.

One more provider detail: every response is wrapped in an envelope shaped as status, requestId and result, so always read the payload from result.

## How to customize

- Rename the environment groups to match the tags your team actually uses, or add more groups beyond production, staging and dev.
- Choose which environments demand the typed name confirmation. Production is the default, but you can require it for staging too.
- Reword the maintenance notice and pick a different Slack channel each time you send one.
- Adjust how much detail the board shows per row versus what is tucked into the detail panel.

## FAQ

### Does this replace the ClickHouse Cloud console?

No. It is a faster front door for the things teams do most often, like checking what is running, seeing the last backup, and starting or stopping a service. Anything unusual still belongs in the console.

### Can someone accidentally shut down a production database?

That is exactly what the safety step prevents. Every state change asks for confirmation, and for anything tagged production the button stays locked until the person types the service name exactly as it appears.

### Why does a service sit in a starting or stopping state for a while?

Starting and stopping a database is not instant. The app keeps checking that service in the background and only shows the new state once it has genuinely settled, so you never see an in-between state presented as the final answer.

### Where do the owner and purpose notes live?

The app stores them itself, so they are shared by everyone who opens it. They are not written back into your database settings, which means you can add context without changing anything about the service.

### What if we do not tag our services by environment?

They still appear on the board, collected in their own untagged group. You can set tags from the detail panel, and rows move into the right group once tagged.

### Will it slow down or hit limits with a lot of services?

The app deliberately spaces out its requests and refreshes in small batches, because the ClickHouse Cloud connection allows only a limited burst of requests at a time. Large fleets load in waves rather than failing.

Use this prompt in General Input: https://www.generalinput.com/prompts/run-your-whole-clickhouse-cloud-fleet-from-one-screen