# Prepare for predictable demand

| Requirement | Approach | Setup |
| --- | --- | --- |
| Request replicas during a known time window | KEDA Cron trigger | [Cron configuration and examples](https://keda.sh/docs/latest/scalers/cron/); select your installed KEDA version. |
| Change min/max replicas or other scaling fields during a window | ScalingPolicy | [Scheduled configuration example](https://docs.kedify.io/features/scaling-policy/#creating-a-scaling-policy). |
| Scale ahead of demand inferred from metric history | Predictive scaler | [Enable Predictor](https://docs.kedify.io/how-to/predictive-scaler-installation/), then [forecast and scale a workload](https://docs.kedify.io/how-to/predictive-scaler-example/). |

If live metrics already provide enough notice, keep [live-demand scaling](https://docs.kedify.io/scalers/). If pods wait for nodes, prepare [node capacity](https://docs.kedify.io/capabilities/node-capacity/) as well.

## Schedule boundaries and lead time

[![Illustrative prepared capacity becomes ready before demand, allowing time for node provisioning and application startup.](https://docs.kedify.io/assets/images/docs/demand-readiness-lead-time.svg)](https://docs.kedify.io/assets/images/docs/demand-readiness-lead-time.svg)

Scroll to exploreDiagram description

Illustrative demand increases after node provisioning and application startup. Prepared capacity is ready before demand, while reactive capacity arrives later. Use measured delays to choose the lead time.

- Set `timezone` explicitly using an IANA zone, such as `Europe/Prague`, or `UTC` for a fixed UTC schedule. Local zones change their UTC offset with daylight saving; transition hours can be skipped or repeated. Avoid placing critical boundaries in those hours and verify both transitions for the installed controller.

- Start the window before demand by at least the measured node-provisioning and pod/model-startup time, allowing for scaling evaluation delays. A scheduled replica count does not mean those replicas are Ready.

- With the normal HPA metric combination, Cron’s `desiredReplicas` supplies a floor during the window; another trigger can request more. Keep `maxReplicaCount` high enough for both.

- At Cron’s `end`, other triggers and `minReplicaCount` still apply. Reaching zero requires `minReplicaCount: 0` and inactive zero-capable triggers; KEDA cooldown and HPA stabilization delay scale-in. Do not use `desiredReplicas: "0"` as an off-hours schedule.

- ScalingPolicy changes configuration fields. Use its [verification and pause procedure](https://docs.kedify.io/features/scaling-policy/#verify-and-reverse-a-policy) to check the target fields and their restoration; do not infer replica readiness from policy activation.

## Forecast lead time

In the [sample workload](https://docs.kedify.io/how-to/predictive-scaler-example/), compare predicted and observed demand using the same units and timestamps. Set the trigger’s [`horizon`](https://docs.kedify.io/reference/predictive-scaler/) to cover measured startup time. Keep a live trigger, and test missing-model behavior before relying on prediction. Use [model exploration](https://docs.kedify.io/how-to/predictive-scaler-model-exploration/) to assess forecast quality and [forecast diagnostics](https://docs.kedify.io/troubleshooting/predictive-scaling/) for ingestion or training failures.

---
Canonical: https://docs.kedify.io/guides/prepare-for-demand/
Source: src/content/docs/guides/prepare-for-demand.md
Documentation index: https://docs.kedify.io/llms.txt