# Quota and limits troubleshooting

Source: https://docs.quake.ai/docs/operate/troubleshooting/quota-and-limits
Markdown: https://docs.quake.ai/docs/operate/troubleshooting/quota-and-limits.md
> Diagnose and resolve quota exhaustion errors across compute, network, and storage services on Quake AI.

---

# Quota and limits troubleshooting

Quake AI enforces per-project quotas on compute, network, and storage resources. When a quota is exhausted, resource creation fails immediately with an error that names the exhausted resource. This page covers how to diagnose which quota is hit, how to free capacity, and when to request an increase.

## Symptom patterns by service

| Service | Symptom | Typical error message |
|---|---|---|
| Compute | Instance creation fails | "Quota exceeded for resources: instances" or "Quota exceeded for resources: cores, ram" |
| Network | Floating IP allocation fails | "Quota exceeded for resources: public_ip" |
| Network | Security group creation fails | "Quota exceeded for resources: security_group" |
| Block storage | Volume creation fails | "VolumeLimitExceeded" or "Quota exceeded for volumes" |
| Block storage | Snapshot creation fails | Quota exhaustion on `snapshots` or `gigabytes` |
| Object storage | Container or object creation fails | HTTP 413 or quota-related 403 |

## Diagnosis

### Check overall quota usage

```bash
openstack quota show --usage
```

This shows each resource type, its limit, and current usage in one view.

You can also check quotas programmatically via the API `/limits` endpoint. The Compute API returns quotas at `GET /v2.1/limits` and the Block Storage API at `GET /v3/{project_id}/limits`. Both return an `absolute` object with `maxTotal*` limits and `total*Used` counters. See the [Compute API reference](/reference/compute/api#limits) and [Block Storage API reference](/reference/block-storage/api#limits) for the full response shape.

### View quotas in the portal

Skyline has no dedicated Quotas or Limits page. The **Dashboard** (the default page after sign-in, left-nav label **Dashboard**, route `/base/overview`) is the quota surface: its panels show per-resource `Limit` against `In Use` for Compute, Network, Block Storage, and Object Storage. Navigate by the left-nav label rather than the URL, which can change between Skyline releases.


Portal vs CLI vCPU mismatch: the Dashboard may show a stricter vCPU limit than `openstack quota show` reports for `cores`. The Dashboard vCPU bound reflects a separate product-level cap, while the `cores` value reflects the OpenStack-level quota that enforces resource creation. The CLI is authoritative for OpenStack-level enforcement, so if you hit a quota error the CLI does not predict, check both surfaces.


### Identify the exhausted resource

`openstack quota show --usage` returns four columns: `Resource`, `Limit`, `In Use`, and `Reserved`. Look for resources where `In Use` equals or exceeds `Limit`. The `Status` column below is a reader annotation; the CLI does not emit it.

| Resource | Limit | In Use | Status (annotation) |
|---|---|---|---|
| `instances` | 10 | 10 | Exhausted |
| `cores` | 20 | 18 | Near limit |
| `ram` | 51200 | 51200 | Exhausted |
| `volumes` | 10 | 6 | Available |
| `gigabytes` | 1000 | 450 | Available |
| `public_ip` | 5 | 5 | Exhausted |

The `public_ip` row covers the floating-IP and public-IP quota family. Its `In Use` count includes router external gateway IPs, not floating IPs alone, so floating IPs and router gateways draw on the same quota. The CLI also reports a separate `floating_ips` row whose `In Use` count can differ from `public_ip`; run `openstack floating ip list` for the authoritative floating-IP count.

### Portal label translation

The CLI and the Skyline Dashboard name the same quota differently. When you cross-reference a CLI error against the Dashboard, translate the resource name:

| Doc / CLI name | Portal Dashboard label | Notes |
|---|---|---|
| `instances` | Instances | Case differs only |
| `cores` | vCPUs (Dedicated) | Dashboard separates dedicated from shared vCPUs |
| `ram` | Memory | CLI reports MiB; the Dashboard shows GiB |
| `public_ip`, `floating_ips` | Public IPs | Left-nav labels the same page "Floating IPs" |
| `security_group` | Security Groups | Portal uses the plural with no underscore |
| `volumes` | Volumes | Same name |
| `snapshots` | Snapshots | Same name |
| `gigabytes` | Size (GiB) | Block-storage size in GiB, not MiB |

### Service-specific quota checks

**Compute resources:**

```bash
openstack server list --status ACTIVE
openstack server list --status SHUTOFF
openstack server list --status ERROR
```

Instances in SHUTOFF and ERROR states still consume quota for instances, cores, and RAM.

**Floating IPs:**

```bash
openstack floating ip list
```

Floating IPs that are allocated but not associated to any instance still consume quota.

**Volumes:**

```bash
openstack volume list
openstack volume list --status available
openstack volume list --status error
```

Volumes in `available` and `error` states consume both `volumes` and `gigabytes` quota.

**Snapshots:**

```bash
openstack volume snapshot list
```

Each snapshot consumes `snapshots` quota and contributes to `gigabytes` usage.

## Remediation

Work through this cleanup sequence, checking quota after each step.

### Step 1: delete ERROR-state resources

These are the safest to remove; they are already non-functional:

```bash
openstack server list --status ERROR
openstack server delete ERROR_INSTANCE_ID

openstack volume list --status error
openstack volume delete ERROR_VOLUME_ID
```

### Step 2: delete unused SHUTOFF instances

Instances that are stopped still consume quota:

```bash
openstack server list --status SHUTOFF
openstack server delete UNUSED_SHUTOFF_INSTANCE
```


Verify that SHUTOFF instances are unused before deleting. Some workloads are intentionally stopped and restart later.


### Step 3: Release unassociated floating IPs

```bash
openstack floating ip list --status DOWN
openstack floating ip delete UNUSED_FLOATING_IP
```

A floating IP with `status: DOWN` is allocated but not associated with any port.

### Step 4: Delete unused volumes and old snapshots

```bash
openstack volume list --status available
openstack volume delete UNUSED_VOLUME

openstack volume snapshot list
openstack volume snapshot delete OLD_SNAPSHOT
```


Delete snapshots before their source volumes. A volume with dependent snapshots cannot be deleted.


### Step 5: Verify freed capacity

```bash
openstack quota show --usage
```

Confirm the exhausted resource now has available capacity, then retry your original operation.

## Requesting a quota increase

If cleanup does not free sufficient capacity, request a quota increase:

1. Check your current plan tier on the [account dashboard](https://portal.rumble.cloud)
2. File a request through the [support portal](https://portal.rumble.cloud/help) with:
   - Which resource(s) need increased limits
   - Current usage and requested new limit
   - Business justification (brief)
3. Quota increases are subject to platform capacity and plan tier availability


Default quotas are set per plan tier. Some increases may require a plan upgrade rather than a per-project adjustment.


## Verification

After cleanup or quota increase, verify the operation that originally failed:

```bash
openstack quota show --usage
```

Then retry the original resource creation.

## Prevention

- Run `openstack quota show --usage` as a pre-flight check before large deployments or batch operations
- Clean up test and development resources after use
- Delete ERROR-state resources on a schedule; they consume quota without providing value
- Monitor quota utilization proactively; do not wait for creation failures
- Use `openstack server list --all-projects` (if you have admin access) to audit resource usage across projects

## Quota CLI commands

### Show quota usage for the current project

```bash
openstack quota show --usage
```

This is the primary diagnostic command. It shows each resource type, its limit, and current usage in one table.

### Show quota limits without usage

```bash
openstack quota show
```

Returns the configured limits without current usage counts.

### List quotas across projects (admin only)

```bash
openstack quota list --compute
openstack quota list --network
openstack quota list --volume
```

### Show API rate and resource limits

```bash
openstack limits show --absolute
```

Returns the same data as the `/limits` API endpoint. The `--absolute` flag shows resource quotas. See [API rate limits](/docs/tools/api-rate-limits) for details on the `/limits` response.

## See also

- [API rate limits](/docs/tools/api-rate-limits): quotas vs. rate limits, the `/limits` endpoint
- [Instance lifecycle troubleshooting](/docs/operate/runbooks/instance-lifecycle)
- [Volume troubleshooting](/docs/operate/runbooks/volume-troubleshooting)
- [Troubleshooting overview](/docs/operate/troubleshooting)
- [Support ticket evidence collection](/docs/operate/troubleshooting/support-ticket-evidence)