Steward
Sign in

Documentation › Concepts

The fleet dashboard

/app is the post-sign-in landing page. For maintainers running more than one repo, the fleet dashboard is the surface most people open every Monday morning. This doc explains what it shows, what each column means, and what to do when something looks off.

What "fleet" means here

A repo enters your fleet the moment the Steward GitHub App is installed on it. The fleet table shows one row per installed repo; the columns aggregate the recent evaluation activity for that repo into a compact health pulse.

Don't confuse the fleet with the per-PR list:

Surface What it shows Where it lives
Fleet dashboard Repo-level health for every installed repo. /app (the FleetCard)
Per-repo PR list Each PR-evaluation row for one repo. /app/repos/<id>/pulls

The fleet dashboard rolls up across all PRs in a time window; the per-PR list is one row per PR. Different scales, different purposes.

The five repo-wide dimensions

Each row carries five compact pills — T C P M G — representing the five dimensions of the repo-wide scorecard (distinct from the five per-PR dimensions).

Glyph Dimension What it measures
T Issue triage Open issue age distribution + how many issues carry a label (proxy for "triaged"). Unknown if issues are disabled or the repo is brand-new.
C Contributor concentration Bus-factor signal. Is most work flowing through one author, or distributed? High concentration = red.
P PR complexity Aggregate diff sizes across recent PRs. A repo that keeps merging 2000-LoC PRs scores red.
M Merge velocity Time-to-merge distribution. Stale PRs sitting open for weeks signal a review bottleneck.
G Governance alignment Whether the repo has a governance.pxf, whether recent PRs map to its domains, whether the gates are firing.

Each pill colours by the same >=75 green, 50-74 amber, <50 red, otherwise unknown rule (Evaluations + dimensions). Hover any pill to see the full dimension name + the underlying score; click through to the evaluation detail to read the evidence.

Columns in the fleet table

Column Meaning Action when off
Repo Full name (owner/name). Link goes to the per-repo dashboard. —
Governance badge The Steward shield icon appears when governance.pxf is committed on the default branch. Click it to open the editor. If missing: write one (Write your first governance.pxf).
Done / Running / Queued / Failed Counts of evaluations in each terminal state within the time window. Failed > 0: see Debug a failed evaluation.
Dimension pills (T/C/P/M/G) Latest repo-wide scorecard. Any red pill: open the per-repo dashboard and read the dimension's evidence.
Sparkline Strip plot of the last 10 evaluations across a 90-day horizon. Visual density shows activity. Quiet repos sparkle empty. That's fine.
Latest Timestamp of the most recent evaluation. Older than your release cadence: the repo isn't getting evaluated. Likely no PRs are landing or the workflow's broken.

The time-window selector

Above the table:

[ 7d ] [ 30d ] [ 90d ]

This selects the window for the Done / Running / Queued / Failed counts and the sparkline. The dimension pills don't change — those reflect the latest evaluation, not the window aggregate.

The choice persists as ?window=N in the URL — refresh-safe and shareable. Default is 30 days.

Window Use case
7d Weekly sweep. "What broke last week?"
30d Monthly review. Default. The right cadence for most teams.
90d Quarterly retro. Hide the sparkline noise of one-off slow weeks.

Reading the table

A typical Monday read:

  1. Scan the dimension pill strips down the right. Any red?
  2. For each red pill, click into the repo's per-repo dashboard. The dimension's evidence is there — number of stale issues, diff sizes, etc.
  3. Glance the Failed column. Anything non-zero is the investigation queue (jump to Debug a failed evaluation).
  4. Sort by Latest column (the default is reverse-chronological — most recently active repo first). Repos that haven't seen activity in weeks are either healthy idle or quietly broken; that's a maintainer judgement.

The aim is to leave /app in under 5 minutes if everything is green, or to have a clear hand-off into the per-repo dashboard when something needs deeper attention.

Gate outcomes — what would have blocked

Below the fleet table, the Gate outcomes panel aggregates structural-gate violations across your repos for the active window. One line per (gate, domain, enforcement) combination, with a colour-coded enforcement badge — red block, amber warn, neutral observe — an event count, and the last-seen date.

The panel exists for the enforcement-mode rollout play: repos running gates in warn or observe record what would have blocked, and that's the signal here. Repos sort noisiest-first by would-block count (warn + observe events), and each row shows N PRs (×M events) — distinct pull requests, not raw events, because one PR re-tripping a gate on five pushes is one affected PR.

The "flip to block?" hint

When an advisory-mode gate would have blocked at most 2 distinct PRs over a 30-day-or-longer window, the row gets an emerald flip to block? chip: the evidence says the bar is already being met, so promoting the gate to block is low-friction. The chip links to the enforcement-modes docs; the change itself is a one-line edit in governance.pxf (or the domain's section in the governance editor). 7-day windows never show hints — too thin to argue from.

An empty panel means no gate violations in the window — either the fleet is clean, or no repo runs gates in advisory mode yet (the empty state links to how to set that up).

When the fleet is too big to scan

A fleet of 50+ repos doesn't fit on one screen. Use the filter controls at /app/repos for serious slicing:

  • Search by name — case-insensitive substring match.
  • Public / Private toggles — handy when one org has both styles and your attention is on one side.
  • Page through — the list paginates after a threshold.

For repeated triage queries (e.g., "any repo with a red T pill"), the API gives you a programmatic version (API reference) — script the question instead of scanning the UI.

What the dashboard doesn't show

Worth knowing what's not on /app:

  • Individual PRs. Use the per-repo PR list (/app/repos/<id>/pulls) for per-PR drilling.
  • Cross-repo contributor reputation. That lives at /app/contributors — orthogonal to the fleet view (it's contributor-centric, not repo-centric).
  • Sponsor / billing surfaces. Visible only if you have a sponsor role on at least one org. The Sponsorships card appears in that case, separately from the fleet.
  • Audit log. Same role-gated rule. The Audit card surfaces when you have org#read on at least one org.

Other cards next to the fleet

/app is persona-aware. Beyond FleetCard, the cards you'll see:

Card Visible to Sits above/below Fleet
Staff Steward staff only Always above (rare for tenants)
PM Project Managers Above
Sponsorships Sponsors / Org Owners Above Fleet (for sponsor-primary users)
Audit Org-readers Between Fleet and Sponsorships
Mentorships Anyone with active mentor / mentee pairings Below Fleet
Contributions Every signed-in user Below Fleet — "where else does Steward see me"
Contributor reports Every signed-in user Below Contributions

For a pure Maintainer (no PM / Sponsor / Staff role), Fleet is at the top and the other cards stack below it.

What's next