Skip to main content

​
Before you start

Complete GitHub setup. 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. For an ARM job, set its runner label as follows.
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. Read the current runner status.
Find your architecture in the returned pools array. Check its state and check time. Check the matching architecture even if the overall status is ready. Confirm the result in Runs after your job finishes.

​
List configured pools

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

​
Check pool details

Open Runners. 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. Do not treat Listening as proof of spare capacity or a successful job. Check a completed job and its runner release in 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.