The lane is visible: queue depth, the running check and its age, median duration and the time to clear, on the home and in /api/v1/health; the 30-minute card names the cause #1277

The owner, 2026-10-13 18:30Z: "still seeing 'The check queue has waited over 30 minutes.' and seeing no crew members working. are we really bottlenecked that hard by CI? why is this so hard for me to observe and follow?"

The answer was yes (43 checks queued, one lane, median 20 minutes each, about 14 hours to clear) and the forge did not say so anywhere. The card says a symptom after thirty minutes; the home does not show the lane; a person has to query the runs table to learn the depth, what is running, for how long, and what would help.

Done looks like:

• [ ] One line on the home, always, when anything is queued: Lane: 43 checks queued · running #1171 for 6 min · median 20 min · clears in ~14 h. The numbers come from the run table (src/kernel/vitals.ts), the median from the last twenty finished checks.
• [ ] The same in /api/v1/health as lane: {queued, running: {pull, since}, medianMinutes, clearsInMinutes} so a steward or an MCP client reads it in one call.
• [ ] The 30-minute card is replaced by the line plus its cause and the lever: one lane; the fast tier applies to pulls branched after 17:12 (#1275 makes it apply to all); the card links the issue that fixes it when one is open.
• [ ] A crew member working is visible on the home as a row (agent, pull, since, what it is doing in one line) whenever a run is active; when none is, the line says why (autonomy off, ceiling reached, nothing ready).
• [ ] Tests in test/vitals.test.ts and test/web.test.ts: the lane line with a seeded run table; the empty state says why.

Parked by the crew: the check failed ("the gate's list > every test/*.test.ts is in exactly one list, and every entry exists") and the decider saw no point in another try (pull #1280 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Owner, 2026-10-15 04:30Z: "there were a ton of working labels that weren't actually working." During the two cutovers (01:04Z, 02:00Z) and the 01:08Z restart, runs whose process died with the pod kept state=running on the board until the boot sweep marked them; the label lied for minutes. Acceptance to add here: a run's working badge is driven by its heartbeat (stale > 90 s → shown as lost, re-queuing), and the home never shows more working than there are live processes.

Parked by the crew: the check stayed red through 2 automatic tries (pull #1440 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.