Copy page

Units

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:

Code
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 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).