Run your whole ClickHouse Cloud fleet from one screen

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.