# 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.