> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tuneplane.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Capacity

> How busy the hardware is, and which hardware there is, on one page at /admin/capacity.

Two tabs at `/admin/capacity`, administrators only. They were always read together: one page says
how busy the hardware is and the other says which hardware there is.

| Tab             | Path              | Answers                                      |
| --------------- | ----------------- | -------------------------------------------- |
| **Utilization** | `/admin/capacity` | How busy has the cluster been                |
| **Fleets**      | `?tab=fleets`     | Which machines exist, and what each Fleet is |

The old `/utilization` and `/fleets` links land here. `?tab=fleets/<fleet-id>` opens one Fleet's
machines, which fill the page on their own.

## The Utilization tab

| Region                     | What it shows                                   |
| -------------------------- | ----------------------------------------------- |
| **Occupancy over time**    | Cards held against cards available, per series  |
| **Range**                  | The period the chart covers                     |
| **Idle and unschedulable** | Free cards, and cards the platform has excluded |

Unschedulable is not busy. A card lands there when health checks found pending ECC retirements or
uncorrected errors, or when a process outside the platform is holding it.

## The Fleets tab

A [Fleet](/en/ops/fleets) is a registered, named set of machines that one backend manages, and it
is the thing a job or a deployment is placed onto.

| Column               | What it is                                                                    |
| -------------------- | ----------------------------------------------------------------------------- |
| **Kind**             | `local`, `node`, `kuberay` or `slurm`. It decides which executor runs the job |
| **Nodes**            | Machines in it, with what each reported at registration                       |
| **Capability**       | Whether it may be used for training, serving, or hosting environments         |
| **Visibility**       | Every project, or named ones only                                             |
| **Inventory status** | `fresh`, `stale`, `unknown` or `partial`                                      |

Those four inventory statuses are never rounded into each other. **An unknown reading proves
nothing**, so it refuses no job and admits none by fallback, and an unreported card count reads as
`null` rather than `0`. A backend that could not be reached is not a cluster with nothing in it.

Discovery says what exists. It never says what is free.

## What you can do

| Action                          | Effect                                         |
| ------------------------------- | ---------------------------------------------- |
| **New Fleet**                   | Register a set of machines under one backend   |
| Mint a Join Token               | **`node` Fleets only.** See below              |
| Drain a node                    | Withhold new work while existing work finishes |
| Change capability or visibility | What the Fleet may be used for, and by whom    |

Only a `node` Fleet registers machines here. Kubernetes owns its nodes, Slurm owns its nodes, and
`local` owns exactly the host the console runs on — so a Join Token, a node credential and a
heartbeat mean something on `node` and nothing anywhere else. Asking for one on a `kuberay` Fleet
is refused rather than producing a record nothing can honour.

External inventory is read-only. The platform does not cordon a Kubernetes node or drain a Slurm
partition: a control plane that mutates somebody else's scheduler needs an argument this one has
not made.

## Next

[Fleets](/en/ops/fleets) · [Hardware](/en/ops/hardware) · [Settings](/en/console/settings)