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

# Check runners

> Choose x64 or ARM runners and check current capacity.

## Before you start

Complete [GitHub setup](/github).
Keep access to your private repository through the Peak GitHub App.

## Choose a runner

Use one of these Ubuntu 24.04 labels for the current pilot.

| Architecture | Runner label            | vCPUs | Memory |
| ------------ | ----------------------- | ----- | ------ |
| x64          | peak-ubuntu-24.04-4     | 4     | 16 GiB |
| ARM64        | peak-ubuntu-24.04-arm-4 | 4     | 16 GiB |

For an ARM job, set its runner label as follows.

```yaml theme={null}
runs-on: peak-ubuntu-24.04-arm-4
```

Keep Windows, macOS, public repositories, and untrusted fork jobs off these runners.
Use the qualified images and shapes above.

Allow for queue time when the pilot fleet is full.
Plan for shared capacity of ten jobs per architecture.
Do not rely on automatic host scaling for larger bursts.

## Check current capacity

Create a token with workspace read access through [API access](/api-access).
Read the current runner status.

```bash theme={null}
curl --fail-with-body https://app.peak.inc/api/v1/runner-status \
  -H "Authorization: Bearer $PEAK_TOKEN"
```

Find your architecture in the returned pools array.
Check its state and check time.

| State       | What to do                                  |
| ----------- | ------------------------------------------- |
| ready       | Submit a job for that architecture.         |
| busy        | Leave the job queued until a slot is free.  |
| paused      | Wait for admissions to resume.              |
| unavailable | Check again when runner health is restored. |

Check the matching architecture even if the overall status is ready.
Confirm the result in [Runs](/runs) after your job finishes.

## List configured pools

```bash theme={null}
npx -y @peakinc/cli@latest login
npx -y @peakinc/cli@latest runners list --json
```

For the next page, pass the cursor from the previous result.

```bash theme={null}
npx -y @peakinc/cli@latest runners list --limit 25 --after NEXT_CURSOR --json
```

## Check pool details

Open [Runners](https://app.peak.inc/app).
If you have a configured pool, find its repository list.
Check its runner label, architecture, vCPU count, and memory.
Use that label in the workflow jobs you want to move.

Check the pool status before you run a job.

| Status          | What to check                                               |
| --------------- | ----------------------------------------------------------- |
| Starting        | Check again for a current listener session.                 |
| Listening       | Check your first job to confirm execution.                  |
| Needs attention | Check for a listener error or lost GitHub access.           |
| Paused          | Confirm that the pool has been resumed before sending jobs. |
| Draining        | Wait for the pool to return to active use.                  |
| Unavailable     | Confirm that your runner type is released and available.    |

Do not treat Listening as proof of spare capacity or a successful job.
Check a completed job and its runner release in [Runs](/runs).

## Check a queued job

1. Match the workflow's runner label to the job's architecture.
2. Check the capacity state for that architecture.
3. Check the GitHub App's repository selection.
4. Reconnect GitHub if asked.
5. Check for a runner group error beside the repository and retry it.
6. If you have a configured pool, check that it is active and listening.

Confirm runner availability before moving more jobs.
Do not use a setup pull request or a released label as proof of active capacity.