> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Article discussing the Scheduled Scaling feature in ClickHouse Cloud
# Scheduled scaling
export const Image = ({img, alt, size = "lg", background}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined;
return ;
};
export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
if (link) {
return
Beta
;
}
return
Beta feature
;
};
ClickHouse Cloud services automatically scale based on CPU and memory utilization, but many workloads follow predictable patterns — daily ingestion spikes, batch jobs that run overnight, or traffic that drops sharply on weekends. For these use cases, Scheduled Scaling lets you define exactly when your service should scale up or down, independent of real-time metrics.
With Scheduled Scaling, you configure a set of time-based rules directly in the ClickHouse Cloud console. Each rule specifies the days it is active, a start and end hour in UTC, and the settings to apply during that window — the number of replicas (horizontal), the minimum and maximum memory per replica (vertical), and whether the service is allowed to idle. While the window is active ClickHouse Cloud applies those settings, then reverts to your default scaling configuration when the window ends, so your service is sized appropriately before demand arrives rather than reacting after the fact.
This is distinct from metric-based autoscaling, which responds dynamically to CPU and memory pressure. Scheduled Scaling is deterministic: you know exactly when the scaling will happen and to what size. The two approaches are complementary — a service can have a baseline scaling schedule and still benefit from autoscaling within that window if workloads fluctuate unexpectedly.
Scheduled Scaling is currently available in **Beta**.
Setting up a scaling schedule
To configure a schedule, navigate to your service in the ClickHouse Cloud console and go to settings. From there, select **Schedule Override** and add a new rule.
Each rule requires:
* **Days active:** The days of the week the rule applies to
* **Start and end time:** The window during which the rule applies, given in **UTC** and on whole hours. A window whose end hour is earlier than its start hour runs overnight into the next day
* **Settings to apply:** The number of replicas, the minimum and maximum memory per replica, and the minimum idle time (or no idling) to use while the window is active
Multiple rules can be combined to form a full weekly schedule, as long as their windows do not overlap. For example, a single rule covering Monday to Friday from 06:00 to 20:00 UTC can hold your service at a larger size through the working day, with your default configuration applying outside that window.
Use cases
**Batch and ETL workloads:** Scale up before a nightly ingest job runs and scale back down once it completes, avoiding over-provisioning during idle daytime hours.
**Predictable traffic patterns:** Services with consistent peak hours (e.g. business-hours query traffic) can be pre-scaled to handle load before it arrives, rather than waiting for autoscaling to react.
**Weekend scale-down:** Reduce replica count or memory tier over weekends when demand is lower, then restore capacity before the Monday morning surge.
**Cost control:** For teams managing ClickHouse Cloud spend, scheduled scale-downs during known low-utilization periods can meaningfully reduce resource consumption without any manual intervention.
A scheduled scaling action and a concurrent autoscaling recommendation may interact — the schedule takes precedence at its trigger time.
Handling spikes in workload
If you have an upcoming expected spike in your workload, you can use the
[ClickHouse Cloud API](/products/cloud/features/admin-features/api/api-overview) to
preemptively scale up your service to handle the spike and scale it down once
the demand subsides.
To understand the current CPU cores and memory in use for
each of your replicas, you can run the query below:
```sql theme={null}
SELECT *
FROM clusterAllReplicas('default', view(
SELECT
hostname() AS server,
anyIf(value, metric = 'CGroupMaxCPU') AS cpu_cores,
formatReadableSize(anyIf(value, metric = 'CGroupMemoryTotal')) AS memory
FROM system.asynchronous_metrics
))
ORDER BY server ASC
SETTINGS skip_unavailable_shards = 1
```