> ## Documentation Index
> Fetch the complete documentation index at: https://docs.baseten.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Schedule autoscaling for traffic
> Change autoscaling settings on a recurring or one-time window instead of running an external cron job.
Autoscaling responds to traffic that has already arrived, so requests at the start of a traffic increase wait behind a [cold start](/deployment/autoscaling/cold-starts) while new replicas start up. When your traffic follows known clock times, you can change the autoscaling settings before the traffic arrives rather than after.
An *autoscaling schedule* is a window on a model [environment](/deployment/environments), recurring or one-time, carrying its own autoscaling settings. While the window is active, the environment runs the schedule's settings. Outside every window, it runs the environment's default configuration. Schedules do this natively, so you don't need an external [cron job](/deployment/autoscaling/traffic-patterns#scheduled-pre-warming) or [GitHub Action](/deployment/ci-cd) calling the [Management API](/deployment/manage/scaling) on a timer.
## How schedules work
Autoscaling defaults to the configuration values you set on the environment. To vary those values by time of day or day of week, define up to 10 schedules, each pairing a recurring window with its own set of autoscaling settings. The schedule whose window covers the current time is the one in effect.
A schedule's window runs on one of three cadences:
* **Daily**: one window a day, between a start and end time, on the days you choose, such as `09:00` to `18:00` on Monday through Friday.
* **Hourly**: a window in every hour, optionally limited to a range of hours, such as `:55` to `:20` during hours `09` to `17`.
* **One time**: a single window between two absolute date-times, such as September 1 at `09:00` to `13:00`. Use one-time schedules for planned events like launches, load tests, and migrations. The window does not repeat, and the schedule stops applying when it ends.
Windows include their start and exclude their end: in a `09:00` to `17:00` window, `09:00` is inside and `17:00` is not. A recurring end time at or before the start wraps past midnight, so a `22:00` to `06:00` window covers the overnight hours. Every schedule on an environment shares one timezone, set once for the whole set. Recurring times are local to it; one-time windows accept any timezone offset and convert to UTC.
## Configure a schedule
You configure schedules per environment, from the same dialog as the rest of your autoscaling settings.
**To add an autoscaling schedule**:
1. Sign in to your workspace at [app.baseten.co](https://app.baseten.co) and choose **Dedicated Inference** in the sidebar.
2. Select your model, then select the deployment for the environment you want to schedule.
3. Choose **Configure autoscaling**.
4. For **Config to edit**, choose **Schedules**.
5. Choose **Add schedule**, then set its window and replicas:
* For **Frequency**, choose **Daily**, **Hourly**, or **One time**.
* For a daily or hourly schedule, select the days it runs under **On days**, then set **Starts at** and **Ends at**. For an hourly schedule, use **Limit to hours** to restrict which hours it runs in.
* For a one-time schedule, set the **Schedule window** start and end date-times.
* Set **Min** and **Max** replicas for the window. To override the remaining autoscaling settings, choose **More options**.
6. Choose **Save**.
If the new schedule's window covers the current time, the environment switches to it as soon as you save. An **Active** badge marks whichever configuration is running.
A start time is the earliest the settings change, not a promise that replicas are ready to serve. If the deployment can't take the change right then, because it's deploying, loading a model, mid [rolling promotion](/deployment/rolling-deployments), or migrating, Baseten applies it as soon as it can.
## Validation
Saving fails if any schedule breaks one of these rules:
* **Count**: up to 10 schedules per environment. Expired one-time schedules don't count.
* **Window length**: at least 5 minutes, long enough to scale up and back down. A one-time window can span at most 48 hours, including back-to-back chains of one-time schedules.
* **Overlap**: two windows can't cover the same time.
* **Gaps**: windows either touch exactly or leave at least 5 minutes between them.
* **Coverage**: schedules can't fill the entire week, so the default configuration always has time to run.
* **Timezone**: one shared timezone per environment.
* **One-time start**: a new one-time schedule must start in the future. You can still edit an existing one-time schedule after its window starts.
* **One-time horizon**: a one-time window can end at most 90 days in the future.
Windows that touch exactly hand off directly. A `05:40` to `09:00` window can hand straight to a `09:00` to `18:00` window with no gap and no return to the default in between.
## Edit or remove a schedule
Changes to the schedule that's currently running apply immediately, not at its next start. Disabling or removing it falls back to the default, or to another schedule whose window covers the current time.
**To edit, rename, duplicate, disable, or remove a schedule**:
1. Sign in to your workspace at [app.baseten.co](https://app.baseten.co) and choose **Dedicated Inference** in the sidebar.
2. Select your model, then select the deployment for the environment.
3. Choose **Configure autoscaling**.
4. For **Config to edit**, choose **Schedules**.
5. Expand the schedule and make your changes:
* To rename, duplicate, or remove it, use the actions menu on its header.
* To pause it without removing it, use the **Enabled** switch.
6. Choose **Save**.
A disabled schedule still has to pass validation, so you can re-enable it later. A one-time schedule stays on the environment after its window passes; remove it when you no longer need it.
## Manage schedules from the API
The [Update environment](/reference/management-api/environments/update-an-environments-settings) endpoint manages the same schedule collection. Each entry in `schedules` is a complete create or replacement: include a schedule's `id` to replace it, or omit `id` to create a new one. Schedules you leave out of the list stay unchanged, and deletion stays explicit through `delete_schedules`.
```json PATCH /v1/models/{model_id}/environments/{env_name} theme={"system"}
{
"autoscaling_schedule_settings": {
"timezone": "America/Los_Angeles",
"schedules": [
{
"cadence": "ONE_TIME",
"name": "Launch day scale-up",
"enabled": true,
"start_at": "2026-09-01T16:00:00Z",
"end_at": "2026-09-01T20:00:00Z",
"autoscaling_settings": {
"min_replica": 4,
"max_replica": 16,
"autoscaling_window": null,
"scale_down_delay": null,
"concurrency_target": null,
"target_utilization_percentage": null,
"target_in_flight_tokens": null,
"max_scale_down_rate": null
}
}
]
}
}
```
The `cadence` field selects the timing shape: `DAILY` and `HOURLY` take the weekday and time-of-day fields, while `ONE_TIME` takes `start_at` and `end_at`. Every `autoscaling_settings` field is required; set a field to `null` to follow the environment's current value. One-time date-times must include a timezone offset, and Baseten converts them to UTC.
The PATCH response reports the requested state, and schedule application reconciles asynchronously. Poll [Get environment](/reference/management-api/environments/get-an-environments-details) to confirm the applied settings.
## Next steps
Match autoscaling settings to the shape of your traffic.
Shrink the time between a scale-up and a served request.
Understand the environments that schedules attach to.
Apply autoscaling changes to a live deployment from a script.