Monitoring Your Fleet

Four views show what your fleet is doing, now and lately. None need setup; they read the state the orchestrator already tracks.

Fleet overview

The home page is a live dashboard of the whole fleet. The KPI tiles count live jobs, queued jobs, total capacity, hosts, workloads, and connected orgs. Below them, per-workload capacity bars show how full each pool is against its ceiling, per-host rows show each host’s live CPU, RAM, disk, and load, and a strip of recent events tails the timeline.

It updates as state changes rather than on a fixed poll, so a saved setting or a new job shows up within about a second.

Note

The host disk gauge reads through the read-only /:/host:ro bind mount the installer adds. A host enrolled before that bind existed shows — for disk until you re-enroll it (see Adding hosts).

Jobs

The jobs page lists GitHub Actions jobs correlated to your runners: status, queue wait, run time, pass or fail, and which runner picked it up.

A badge near the page title reports for how many of your orgs webhooks are active. Enabling webhooks for an org makes its job history complete — without them the job list is filled by polling, which is accurate but may miss short-lived jobs between polls.

Idle vs. busy runners

A status poll every 30 seconds checks GitHub and splits your live runners into idle and busy, so the UI shows which runners are executing a job versus waiting for one. This poll only reads state; it never spawns or removes anything.

Events

The events page is a filterable, append-only timeline. It records reconciler decisions (spawns, reaps, drains), backoff transitions, GitHub and Docker incidents, and runner state changes. Entries are kept for 14 days by default and then swept. Use it as your first stop when a runner doesn’t appear or a host goes quiet.

A Download diagnostics button in the page header exports the recent log plus a snapshot of your fleet as one redacted JSON file — attach it when reporting a problem.

Cost savings

The cost-savings view estimates what the same work would have cost on GitHub-hosted runners. It runs the numbers against the lowest GitHub-hosted tier. Larger hosted runners cost more, so your real savings are at least what’s shown. Treat it as a floor, not an invoice.