# The Runners page: fleet management

> Manage your runner fleet from the dashboard: runner types, configurations, usage and savings, the self-healing activity feed, and the bulk migration tool.

Source: https://latchkey.dev/documentation/runners-dashboard

## Summary

- The **Runners** page = fleet cost and savings, runner configurations, and the self-healing activity feed.
- Per-configuration enable/disable, max concurrency, and image build status for custom runners; self-healing is controlled workspace-wide in Settings.
- **Migrate Runners** (sidebar item or Runner Types card, owners/admins) opens one PR per repository, up to 20 monitored repos per pass; only `runs-on` lines change, plus Latchkey cache steps when added.

Everything about your managed runner fleet lives on the **Runners** page ("Manage your runners and review jobs they've run") in the dashboard sidebar. It is the operational home for the features described in the rest of this section.

## What is on the page

- **Fleet metrics** Runner cost this billing period, estimated savings vs GitHub-hosted, and free-tier minutes used against your monthly allowance.
- **Runner Types** A collapsible card covering Preset Runners (the four sizes with specs and per-minute pricing) and AI Scan Runners, with a Migrate Runners shortcut in its footer.
- **Your runners** Every configuration in your workspace: name, status, size, max concurrency, self-healing state, and on/off, plus a per-row Copy CI snippet action.
- **Self-Healing activity** Heal KPIs (Total Attempts, Heals, Success Rate), activity and category charts, and the Recent Heals feed.

## A five-minute weekly review

The page rewards a short weekly habit. A suggested pass:

**Weekly fleet review**
- [ ] Fleet metrics: is runner cost tracking where you expect for this billing period, and how much of the free-tier allowance is left?
- [ ] Estimated savings vs GitHub-hosted: still what you expect? It is your ongoing evidence the migration keeps paying off.
- [ ] Your runners: is anything disabled that workflows still target? Jobs aimed at a disabled label queue rather than fail, which is easy to miss.
- [ ] Custom runners: any image builds still pending, or failed? The configuration row shows build status.
- [ ] Recent Heals: which categories dominate this week, and is any single workflow being healed repeatedly?

## The Your runners table

The **Your runners** table ("Set up runners for your repos. Adjust size, concurrency, and on/off state.") lists every configuration in your workspace: the four presets plus any custom runners. Columns cover name, status, size, max concurrent, self-healing state, and active state, and the table header carries the **AI Scan Runners** action; before your first runner it shows a **Set up your first runner** empty state, and pending scan banners ("Ready for review") appear above it. Each row gives you:

- **Enable/disable.** A disabled configuration stops accepting new jobs (jobs targeting its label will queue).
- **Copy CI snippet**, so nobody types a label from memory.
- A **Self Healing** column showing whether healing covers the runner; the control itself is the workspace-wide switch in **Settings, Self-Healing**.
- **Image build status** for [custom runners](/documentation/custom-runners): you can see when a custom image is still building versus ready.
- **Delete** for custom configurations you no longer need.

Disable and delete do different jobs. Disable is the pause button: the label keeps existing, and jobs that target it queue until you re-enable it, which makes it the right move while you investigate a configuration. Delete is for custom configurations you are permanently done with.

### The detail drawer

Clicking a row opens the detail drawer with the full configuration: label, OS, vCPUs, RAM, disk, base image, and per-minute price, plus a **Use in CI** card with the label and a copyable GitHub Actions snippet. Admins can edit the runner name, custom labels, and **Max Concurrent** (0 = unlimited); non-admins see the same details read-only, so the whole team can see what each runner provides.

## Recent Heals

The Self-Healing section ("Recent heal attempts, agent reports, and PR proposals across your org.") lists every heal with its outcome badge (Healed, No Action, Failed, or Pending) and category, under the heal KPIs and the **Heal Activity Over Time** and **Heal Rate by Category** charts. Clicking a row opens the **Heal Details** drawer with the full report: what failed, the diagnosis, the exact action taken (in plain language), and for AI-diagnosed failures the agent's iterations. Healed runs in [Pipeline Performance](/documentation/pipeline-performance) deep-link into the same reports. If self-healing is off, the section shows "Self-Healing is disabled." with a link to enable it in Settings.

Read the feed as a signal, not just a rescue log. Scattered one-off network heals across many workflows are the normal background noise of registries and external services having bad moments. Patterns are more interesting: the same workflow healed repeatedly in the same category points at something durable. Recurring memory heals suggest a job that wants a [bigger runner size](/documentation/runners-overview); recurring disk heals, a job that fills its disk every run; recurring tool heals, a step that assumes a tool the workflow never installs. Those are exactly the cases where a permanent fix beats being rescued every night; see [heal pull requests](/documentation/self-healing) for how self-healing proposes those fixes itself.

## Migrate Runners

The tool has two entry points, and both open the same **Migrate runners** modal: the **Migrate Runners** item in the dashboard sidebar, and the CTA in the Runner Types card footer ("Already have workflows on GitHub-hosted runners? Migrate them to Latchkey runners in a few clicks."). This section covers the modal itself; the full guide, including the exact label mapping, PR contents, verification, and rollback, is [Migrate from GitHub-hosted runners](/documentation/migrate-from-github-hosted).

Each pull request rewrites every supported `runs-on` label to the right Latchkey size (standard Ubuntu labels become `latchkey-small`) and touches nothing else; Windows and macOS jobs, unrecognized labels, and lines with `${{ }}` expressions are left alone. A before and after mapping table for each file shows exactly what changed, so review takes minutes, not days.

- Once the PRs are open, the modal lists each one with its PR number and a View PR link: "Opened N pull requests. Merge each on your schedule."
- If a repository already has an open migration pull request, Latchkey links to it instead of opening a duplicate.
- If there is nothing left to switch, the modal shows a **Nothing to migrate** state.
- Opening migration PRs requires an admin or owner role; nothing in your repositories changes until your team merges.

> ****
> Fleet cost numbers on this page always reflect the current billing period, so they match what the billing modal will charge, independent of the date filter used on analytics pages.

### What is on the Runners page?

Fleet cost and savings, your runner configurations, and the self-healing activity feed in one place. Each configuration can be enabled or disabled, given a maximum concurrency, and shows image build status for custom runners.

### How do I migrate repositories to Latchkey runners in bulk?

Use Migrate Runners, in the sidebar or on the Runner Types card, available to owners and admins. It opens one pull request per repository across up to 20 monitored repositories per pass, changing only `runs-on` lines plus Latchkey cache steps where those are added.

### Where do I turn self-healing on or off?

In Settings, workspace-wide, not per configuration. The Runners page controls per-configuration enablement and concurrency; self-healing is a single workspace switch so its behaviour cannot drift between runner types.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt