Limits
Limits keep one mistake from becoming a large bill, and keep the shared platform fair. Reaching a limit never stops a unit that is already running. The request that would exceed it is refused or recorded, with the reason.
The figures below are the launch defaults. Your Workload's own ceilings are in the API: max_units, included_units and organization_limits in GET .../units.
| limit | default | notes |
|---|---|---|
| Units per Workload | the product's maximum, 20 for the Workload product | also capped by your organization's limit and by your policy's own max_units |
| Units per organization | 20 | staff can raise it |
| Unit starts per hour, per organization | 60 | counted from pod starts; a flapping policy uses these up |
| Units with a shared volume | 1 | refused with volume_locks_to_one_unit |
| Spend on extra units | your spend_cap_cents, if set | scaling refuses to grow at the cap |
| Public ports | the plan's included slots (none for a Workload) plus those you add | port_limit when full |
| Log lines per second per container | 500 | the rest go to the archive, not away |
| Log and metric retention | 30 days | includes scaled-away units |
| Search text | 200 characters | substring, not a regular expression |
| Log page size | 2000 lines | default 500 |
What a refusal looks like
A scaling refusal is recorded as a decision with a reason (org_limit, spend_cap, no_capacity, at_max), so you can see it on the unit-count chart rather than wonder why the count did not move. A refused policy update returns the reason in details, with a reason code before the colon, and a policy that cannot be saved because of a limit is not partly applied.
no_capacity means the platform had no room to place another unit in your region right now. It is not your limit; the evaluator tries again on its next pass.
Raising a limit
Open a support ticket and say which limit and why. Staff can raise the per-organization limits.