GitHub Actions macOS runner job remains queued while matching runner shows Ready

[BaraniT-PE]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner

Discussion Details

Description
We are seeing an issue in our GitHub Enterprise environment where an iOS workflow job remains queued and does not start, even though the matching runner appears Ready in the UI.

Workflow / Job
Here is the snapshot of the yml

concurrency:
  group: ios-qa-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read
...
jobs:
  ios-qa-build:
    name: Build iOS QA (Fastlane Match)
    runs-on:
      group: Mobile - iOS
      labels: [ghe-runner-macOSARM64-os26]

Observed behavior
The job stays queued with a message indicating that all matching runners are busy / waiting for a runner to pick up the job.
At the same time, the runner:

ghe-runner-macOSARM64-os26
runner group: Mobile - iOS

appears as Ready in the UI.

This creates an inconsistency between scheduler/job state and runner availability shown in the interface. Its indefinitely waiting for hours together. I've tried re-running jobs multiple times with only label mentioned above and in combination as well. Nothing worked out.

Why we are raising this
We have already verified that the workflow syntax is valid and that the requested runner group and label match the runner shown in the UI. The issue appears to be with runner assignment rather than workflow logic.

We have also checked against the following

• Max concurrency - 10
• Check Runner Availability - The status shows under Settings -> Actions -> Runners -> shows the runner is ready
• Job dependencies - None
• Policies restricting runner groups - So far nothing is restricted

Runner config:

• 3 M1 cores, 7GB RAM, 14GB SSD
• Macos-agent -> MacOS 26
• Platform - macOS ARM64

What we need help confirming
Please help determine whether this is due to:

• runner config mentioned above which is not correct
• runner scheduling/capacity behavior
• a runner eligibility or assignment issue
• a runner group restriction issue
• concurrency throttling
  or a UI/state mismatch where the runner shows Ready but is not actually assignable.
• the label maps to a limited hosted macOS ARM pool
• the runner is “registered/visible” but not currently schedulable
• the scheduler sees all backing instances as occupied

I was checking these issues in the past, but it wasn't enough to help me

[Issue 1] (https://github.com/orgs/community/discussions/147604?utm_source=openai)
[Issue 2] (https://github.com/orgs/community/discussions/186184?utm_source=openai)

I would appreciate if someone could advise on this as I got stuck in the loop. If it is one of the above, Please advise how to fix it?

Regards,
BT

[vishalvivek14332-source]

Since the runner is visible as Ready and you've already verified the workflow syntax, labels, runner group, concurrency settings, and permissions, this sounds less like a workflow configuration issue and more like a runner assignment or scheduler problem.

A few additional things to check:

• Verify that the runner is actually online and actively polling GitHub. A runner can sometimes appear "Ready" in the UI even if the runner service has stopped communicating correctly.
• Check the runner's diagnostic logs (_diag folder) for any errors related to job polling, authentication, or connectivity.
• Confirm that the runner's labels exactly match the workflow request (labels are case-sensitive), and that the runner belongs to the correct runner group with access to the repository.
• If this is a self-hosted runner, try restarting the runner service or re-registering the runner. This can resolve cases where the UI state doesn't reflect the scheduler's view.
• Review whether another queued job with the same concurrency group (ios-qa-${{ github.ref }}) is blocking execution. A stuck workflow in the same concurrency group can prevent subsequent jobs from starting.
• If you're using GitHub Enterprise Server, verify that the Actions service and runner versions are compatible, as version mismatches can sometimes cause scheduling issues.

Since the job remains queued for hours while the runner reports Ready, there is also the possibility of a scheduler/state mismatch or an internal issue with runner assignment. If none of the above resolves the problem, I'd recommend opening a GitHub Enterprise Support ticket and including:

• The workflow run ID and job ID.
• The runner ID and runner version.
• Screenshots showing the runner as Ready while the job remains queued.
• Runner diagnostic logs from the _diag directory.

That information should help GitHub determine whether this is a scheduler issue, runner eligibility problem, or an Enterprise-specific bug.