The Runners page: fleet management

Manage your runner fleet from the dashboard: configurations, per-runner self-healing toggles, usage and savings, the Recent Heals feed, and the bulk migration tool.

Everything about your managed runner fleet lives on the Latchkey Runners page 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 metricsRunner cost this billing period, estimated savings vs GitHub-hosted, and free-tier minutes used against your monthly allowance.

Runner TypesThe preset sizes with specs and per-minute pricing, always at hand when picking a label.

Your runnersEvery configuration in your workspace: size, image build status, max concurrency, on/off state, and a per-row Copy CI snippet action.

Self-Healing activityHeal KPIs, trends, category breakdown, 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 lists every configuration in your workspace: the four presets plus any custom runners. Each row shows the size, image build status, max concurrency, and on/off state, plus a per-row Copy CI snippet action so nobody types a label from memory. Each row gives you:

Enable/disable. A disabled configuration stops accepting new jobs (jobs targeting its label will queue).
Per-configuration self-healing toggle, on top of the workspace-level mode in Settings, so you can exclude a specific runner type from healing.
Image build status for 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 per-configuration healing toggle is the precision tool: it lets you keep self-healing on everywhere except one runner type, without touching the workspace-wide mode in Settings.

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 lists every heal with its verdict and category. Opening a row shows 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 deep-link into the same reports. If self-healing is off, this section links you to the Settings toggle.

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; 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 for how self-healing proposes those fixes itself.

Migrate Runners#

01Open the toolFrom the Runner Types card (owners and admins)

02Pick repositoriesUp to 20 monitored repos from a searchable list

03Open migration PR(s)Latchkey opens one pull request per repository

04Review and mergeNothing changes until your team merges each PR

Each pull request rewrites every supported runs-on label to a Latchkey runner: standard Ubuntu labels switch to latchkey-small, the lowest-cost size, and other supported labels switch to the smallest Latchkey size that meets their CPU and memory. Only runs-on lines change; as each PR body puts it, "Only runs-on: lines were touched. Every other line in each file is byte-identical." 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.

The tool deliberately leaves some things alone: Windows and macOS jobs, self-hosted labels it does not recognize, and matrix expressions like ${{ matrix.os }} (including matrix axis definitions). Those jobs keep running exactly where they run today, so you can migrate your Linux jobs now and leave mixed-OS workflows safely intact.

A suggested rhythm for the tool: migrate in waves rather than all at once. Move your first workflow by hand (one line of YAML), let it run for a week, then bring the bulk of the fleet over once you trust the numbers you see here.