# Fixed and autoscaled policies
A Workload's **scaling policy** decides how many units run. A Workload that was never given a policy is `fixed` at one unit.

## Fixed

`fixed` means "run exactly N units". You change N yourself, and it applies at once: raising it starts units, lowering it removes them.

Use `fixed` when you know how much capacity you want, when you want high availability with a constant number of copies (for example two, so one can restart while the other answers), or when you want a predictable bill.

In the API a fixed policy has `min_units` equal to `max_units`. If you send only one of the two, the other is set to match.

## Autoscaled

`autoscaled` means "run between `min_units` and `max_units`, and let Zaroz move within that range". You choose what drives it. At least one of these is required:

- **A CPU target**, as a percentage of the CPU each unit is allowed to use (`cpu_target_percent`).
- **A memory target** (`memory_target_percent`).
- **A schedule rule**: a five-field cron expression, a time zone and new bounds that take effect when it fires and hold until the next rule fires.

### How the count is chosen

About every 30 seconds Zaroz looks at the average load across your ready units and works out how many units would bring it back to the target:

```text
wanted = ceil(current units x current load / target)
```

Example: 2 units are running at 95% CPU against a 60% target. `ceil(2 x 95 / 60) = ceil(3.17) = 4`, so the policy asks for 4 units. If you set CPU and memory targets, the larger answer wins. The result is always held inside `min_units` and `max_units`.

A small band of about 10% around the target counts as "close enough" and changes nothing, so the count does not jitter.

### Not flapping

Two settings keep the count steady:

- `scale_up_cooldown_seconds`: after adding units, wait this long before adding more.
- `scale_down_stabilisation_seconds`: only remove units once the lower count has been enough for this long.

Scaling up is quick on purpose; scaling down is slow on purpose.

### A spend cap

`spend_cap_cents` is the most, in cents, that extra units may cost in a calendar month. At or over it, scaling refuses to grow. Running units are never killed because of the cap, so the bill can overshoot by at most one evaluation's worth of growth (about 30 seconds of the units added in that step).

## Every decision is written down

Each time the evaluator changes the count, or declines to, it records a decision with a plain sentence: what happened and why. For example "Scaled 2 to 4: CPU at 95% against a 60% target". Reasons include `cpu_high`, `cpu_low`, `memory_high`, `schedule`, `cooldown`, `stabilising`, `spend_cap`, `org_limit`, `no_capacity`, `at_max` and `metrics_unavailable`. Consecutive identical decisions are folded into one entry with a repeat count. Decisions are kept 30 days, and the console shows them as markers on the unit-count chart.

## Look before you commit

`POST .../units/policy/quote` takes the same body as the update and returns what the policy could cost in the worst case, without saving anything. Use it before every change that raises `max_units`. The [scaling guide](/guides/containers-scale) shows it.

## Changing the policy

- Changing a policy while the Workload is stopped is allowed and applies when it starts.
- Stopping a Workload stops all its units; starting it brings them back.
- A template change (a new image, new settings) reaches units by a **rolling** rollout, one unit at a time, so the Workload keeps answering.
- `max_units` can never exceed what the product allows or what your organization's limit allows (see [Limits](/units/limits)).