You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci: standards sync PR #9076 waited 3.5 h behind a hosted ubuntu-24.04 runner queue #9139
On 2026-10-22, standards sync PR #9076 waited about 3.5 hours to merge: opened 14:23Z, merged at about 17:55Z. The previous sync PR, #9068, took 10 minutes. The checks themselves passed; the time was spent waiting for runners.
At 16:38Z this repository had 20 workflow runs queued and 6 in progress.
The superseded ci-status run on the earlier head failed by design ("superseded by full run … in flight"). A REST watcher that treats any failed check as final stops on that.
At 18:05Z the queue was down to 3 runs, so the backlog was temporary.
Why it matters
Every cross-repo change that needs a standards sync first, such as a ci-workflows pin bump whose runner-policy contract arrives through the sync, waits behind this queue. It cost #9074 about 3.5 hours.
Open question
Which runs filled the hosted ubuntu-24.04 queue between 14:30Z and 17:30Z? Two possible causes:
the org's hosted-runner concurrency limit;
one workflow fanning out.
The fix differs: move jobs to the managed fleet, or add a concurrency group to the workflow that fans out. A per-workflow breakdown of queued time for that window would settle it.
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: on 2026-10-22, standards sync PR #9076 spent about 3.5 hours waiting on the hosted ubuntu-24.04 queue. The checks passed. The open question is what filled that queue between 14:30Z and 17:30Z: the org's hosted-runner concurrency limit, or one workflow fanning out. A per-workflow breakdown of queued time for that window would settle which fix applies: move jobs to the managed fleet, or add a concurrency group.
Nothing else is missing. The first step is read-only: pull the run data for that window and attribute the queued time. No likely duplicates found among the open issues.
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
melodic-automation-lanes commented on Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: A per-workflow breakdown of queued time on hosted ubuntu-24.04 for 2026-10-22 14:30Z-17:30Z attributes the backlog to the org runner limit or to one fanning-out workflow, and a follow-up fix issue is opened.
Can an unattended run query Actions run data for that window? The checkout holds no queue data, and the org-level data may need admin access.
RECOMMENDED: Have a person or an admin-token job export created_at and started_at per workflow for 2026-10-22 14:30Z-17:30Z and attach it to the issue. Basis: judgment
Should the deliverable be a report only, or also a fix (managed-fleet move or concurrency group)?
RECOMMENDED: Report only; open a separate fix issue once the breakdown names the cause. Basis: judgment
What is the org hosted-runner concurrency limit, and is moving jobs to the managed fleet acceptable to the owner?
RECOMMENDED: The owner states the limit and approves or rejects the managed fleet before any move. Basis: judgment
Should the superseded ci-status failure be handled here or left to the existing issue?
RECOMMENDED: Leave it to #9113 and keep this issue to queue attribution. Basis: 9113
Sources read
/home/runner/work/_temp/refine-data/context.json: the issue asks which runs filled the hosted queue and includes no run data
/home/runner/work/claude-code-plugins/claude-code-plugins/.base/.github/workflows: 103 runs-on ubuntu-24.04 occurrences across 30 workflows (pr-unblock.yml 22, pr-require-checks.yml 12, intake-triage.yml 8), so many workflows could fan out
Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.
Activity
github-actions commentedon Oct 22, 2026
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: on 2026-10-22, standards sync PR #9076 spent about 3.5 hours waiting on the hosted
ubuntu-24.04queue. The checks passed. The open question is what filled that queue between 14:30Z and 17:30Z: the org's hosted-runner concurrency limit, or one workflow fanning out. A per-workflow breakdown of queued time for that window would settle which fix applies: move jobs to the managed fleet, or add a concurrency group.Nothing else is missing. The first step is read-only: pull the run data for that window and attribute the queued time. No likely duplicates found among the open issues.
Automated triage, applied by the lanes App.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 26, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 26, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.melodic-automation-lanes commentedon Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: A per-workflow breakdown of queued time on hosted ubuntu-24.04 for 2026-10-22 14:30Z-17:30Z attributes the backlog to the org runner limit or to one fanning-out workflow, and a follow-up fix issue is opened.
Related work
Open questions
RECOMMENDED: Have a person or an admin-token job export created_at and started_at per workflow for 2026-10-22 14:30Z-17:30Z and attach it to the issue. Basis: judgment
RECOMMENDED: Report only; open a separate fix issue once the breakdown names the cause. Basis: judgment
RECOMMENDED: The owner states the limit and approves or rejects the managed fleet before any move. Basis: judgment
RECOMMENDED: Leave it to #9113 and keep this issue to queue attribution. Basis: 9113
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.