Pimp My IDE / Garage Dispatch
Back to the garage
October 5, 2026 | CI / runners / release proof

Queued is not failed.

GitHub Actions spent part of October 5 delaying hosted-runner assignment and workflow starts. That incident exposed a release habit worth fixing. A CI badge should not collapse trigger acceptance, runner assignment, step execution, and test conclusion into one verdict.

The take: ask where the run stopped before you rerun it, edit the workflow, or blame the patch. No runner means no test result.

The queue jam was real.

GitHub opened an Actions incident at 19:11 UTC. Four minutes later it named delays in assigning GitHub-hosted runners. At 20:39 UTC, GitHub said job failures and assignment delays were affecting workflow start times. The component moved to a major outage at 20:47 UTC.[1]

At 21:32 UTC, GitHub said mitigations were applied, queued jobs were clearing, and new jobs were not delayed. At 21:54 UTC, the status record said Actions was operating normally. The incident record was still marked investigating, and Pages still showed degraded performance when this dispatch was written. GitHub had not published a root cause.[1]

A run waiting for a machine has not tested your code.

The badge hides four different receipts.

A workflow can be accepted without receiving a runner. A job can receive a runner without reaching the step that matters. A step can run without producing the conclusion your release rule expects. Keep those transitions separate.

GitHub's jobs API exposes fields that help: status, conclusion, started_at, completed_at, runner_name, and per-step status. The workflow-run webhook also has separate requested, in_progress, and completed activity types.[2][3]

That is enough to state the narrow fact. If the job stayed queued and has no runner or start time, report an assignment delay. Do not report a test failure. If steps ran and the job concluded failure, then inspect the failed step and logs.

Do not make the outage write your patch.

Rerunning is useful after service recovery, but a rerun is a new attempt. GitHub says reruns use the original actor's privileges, GITHUB_SHA, and GITHUB_REF. Save the attempt number and timestamps so the recovered run does not erase the stalled one.[4]

Do not change caches, timeouts, matrices, or test commands until you know the workflow reached them. Platform trouble and repository trouble can happen together. The first task is classification, not optimism.

Keep a small incident packet.

  1. Record the run ID, attempt, commit SHA, event, creation time, and update time.
  2. Record each job status, start time, completion time, runner name, and conclusion.
  3. Attach the status-page incident and the update that overlaps your timestamps.
  4. After recovery, rerun the same revision and compare attempts before changing code.
Interactive makeover / CI state triage

Runner assignment airlock

Traditional purpose replaced: one CI status badge. Better version: place the run at one ordered stage, select the evidence sections to collect, and copy a packet that does not turn a queue delay into a test verdict.

Observed run stage
Packet sections selected
Trigger acceptedConclusion recorded
QUEUED / 4 SECTIONS OPEN

Queued selected. This state does not prove that any test ran.

Sources read, not vibes

  1. GitHub Status, "Incident with Actions", October 5, 2026. First-party incident timeline for runner-assignment delays, workflow start delays, component states, mitigation, and the recovery update.
  2. GitHub REST API documentation, workflow jobs, read October 5, 2026. Job status, conclusion, timing, runner, labels, and step records.
  3. GitHub webhook documentation, workflow_run, read October 5, 2026. Separate requested, in-progress, and completed activity types.
  4. GitHub Actions documentation, re-running workflows and jobs, read October 5, 2026. Rerun permissions, original SHA and ref behavior, attempt review, and rerun controls.
  5. Hacker News item 49969961, October 5, 2026. Discussion and discovery route. The GitHub status record supports the incident claims.

Source boundary. GitHub had not published a root cause when this dispatch was written. Pimp My IDE did not inspect a reader's repository or run history. The airlock builds a review packet. It does not fetch API data, prove runner assignment, validate a conclusion, or perform a rerun.