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.

[BaraniT-PE]

Thanks @vishalvivek14332-source for your response. But it is a Github-host runner. My apologies for not mentioning earlier. Not sure if I need create an Enterprise support ticket.

[initial-d]

One thing I would verify very explicitly here: the scheduler matches runner group + labels, not the runner display name.

In your example:

runs-on:
  group: Mobile - iOS
  labels: [ghe-runner-macOSARM64-os26]

ghe-runner-macOSARM64-os26 must be an actual runner label on an online idle runner that is available to this repository. It is not enough for that to be the runner name shown in the UI.

GitHub documents the routing behavior here: https://docs.github.com/en/actions/reference/runners/self-hosted-runners#routing-precedence-for-self-hosted-runners

The important detail is that GitHub looks for an online and idle runner matching the requested labels and groups. If it finds one but the runner does not pick up the job within 60 seconds, the job is re-queued; otherwise the job remains queued until a matching runner comes online.

I would narrow it down with this checklist:

1. From the repository that owns the workflow, go to Settings -> Actions -> Runners -> Self hosted, and confirm the runner appears there. Do not only check the org/enterprise runner list. If it does not appear from the repo view, the runner group access policy is still excluding that repo.

2. Open the runner details and confirm that ghe-runner-macOSARM64-os26 is listed under Labels. If it is only the runner name, add it as a custom label or change the workflow to use an existing label.

3. Use the API to compare what GitHub thinks is assignable:

gh api repos/OWNER/REPO/actions/runners \
  --jq .runners[] | {name, status, busy, labels: [.labels[].name]}

For an organization runner, also compare the org-level view:

gh api orgs/ORG/actions/runners \
  --jq .runners[] | select(.name=="ghe-runner-macOSARM64-os26") | {name, status, busy, labels: [.labels[].name]}

4. Temporarily remove the custom label constraint and test only the group, or test with a very simple workflow:

jobs:
  route-test:
    runs-on:
      group: Mobile - iOS
    steps:
      - run: uname -a

If that starts, the group is accessible and the problem is label matching. If that still queues, the problem is group access/capacity/scheduler state rather than the label.

5. Check the runner service logs in _diag during the queued period. If GitHub assigned a job and the runner failed to accept it, the runner-side logs should show listener/auth/connectivity errors. If the logs show no assignment attempts at all, the scheduler does not consider that runner eligible for the job.

My guess from the YAML is either:

• ghe-runner-macOSARM64-os26 is the runner name but not a label, or
• the runner is visible at org/enterprise level but not actually available to this repository through the Mobile - iOS group policy.

If both checks pass and the simple group-only route test still queues for hours, then I would open an Enterprise Support ticket with the run ID, job ID, runner ID, runner version, group name, labels, and _diag logs, because at that point it looks like scheduler state rather than workflow syntax.

[BaraniT-PE]

Thanks @initial-d for your response. But didn't realise that I have not mentioned the runner type. My apologies!. it is a Github-hosted runner and not the Self-hosted one. I tried with just the runs-on - macos-26 besides the label above. But its still the same.

[initial-d]

Thanks for clarifying that it is GitHub-hosted.

In that case I would treat this differently from a self-hosted runner issue. The runner name you mentioned earlier, ghe-runner-macOSARM64-os26, looks like a runner/runner-group visible in the UI, but for a GitHub-hosted job the scheduler still has to match the workflow label and any runner-group policy that applies to the repository.

A couple of things I would check:

1. Test the smallest possible workflow with only the standard hosted label:

jobs:
  test:
    runs-on: macos-26
    steps:
      - run: sw_vers
      - run: uname -m

2. If your organization requires a runner group for GitHub-hosted macOS runners, use the group form instead of combining unrelated labels:

jobs:
  test:
    runs-on:
      group: Mobile - iOS
      labels: macos-26
    steps:
      - run: sw_vers
      - run: uname -m

3. I would avoid using both macos-26 and ghe-runner-macOSARM64-os26 in the same runs-on expression unless GitHub shows ghe-runner-macOSARM64-os26 as an actual workflow label for that GitHub-hosted runner. When runs-on is an array, all labels must match, so mixing a standard hosted label with a custom/self-hosted-looking label can leave the job with no eligible runner.

4. If runs-on: macos-26 alone still queues indefinitely, then I would ask an org/admin to check policy and capacity rather than the YAML:

• whether standard GitHub-hosted runner labels are disabled or restricted for the org/repo
• whether the Mobile - iOS runner group allows this repository/workflow
• macOS hosted runner concurrency for the org/enterprise
• billing/minutes/quota for macOS hosted runners
• any enterprise policy limiting macOS hosted runner access

GitHub added more org-level controls for hosted runners recently, including restricting standard labels and placing macOS hosted runners into runner groups, so the UI can show a runner/group as ready while this repository still cannot be scheduled onto it.

[BaraniT-PE]

Thanks @initial-d for your reply. I tried both the approaches mentioned above. Here is the snapshot for second one that it is currently running which means it could be related to one of the points mentioned in your last point above.

If not, not sure if we need to reach out to Github Enterprise support ticket. If something else, you could think of please advise.

[initial-d]

Thanks, that result is actually a very useful signal.

If the second test you ran was the group-based one using labels: macos-26, and that job is now running, then I would not treat this as a general macOS hosted-runner capacity problem or a repository access problem. It means:

• the Mobile - iOS runner group is accessible from this repository/workflow
• the org/enterprise policy is allowing this repo to use the macOS hosted runner through that group
• there is at least some macOS capacity available for that route

That points back to the original selector:

runs-on:
  group: Mobile - iOS
  labels: [ghe-runner-macOSARM64-os26]

Most likely ghe-runner-macOSARM64-os26 is not a workflow label that the scheduler can use for that GitHub-hosted runner from this repo. It may be a runner name, an internal/admin display name, or a label that is not actually attached/available in the group. For GitHub-hosted macOS 26, the documented standard labels are things like macos-26, macos-26-intel, macos-26-large, and macos-26-xlarge.

So my recommendation would be:

1. Use the working form for the real workflow:

runs-on:
  group: Mobile - iOS
  labels: macos-26

2. If you specifically need the runner behind ghe-runner-macOSARM64-os26, ask the org/enterprise Actions admin to open that runner entry and check its workflow label / assigned label, not just the runner name shown in the UI.

3. Only open an Enterprise Support ticket if the admin confirms that ghe-runner-macOSARM64-os26 is intended to be a valid workflow label for that hosted macOS runner but jobs using it still remain queued. In that ticket, include both run IDs: the failed run using ghe-runner-macOSARM64-os26 and the successful run using macos-26. That comparison should make the scheduler/label issue much easier for GitHub Support to verify.

References:

• Choosing runners / runs-on: https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job
• macOS 26 labels: https://github.blog/changelog/2026-02-26-macos-26-is-now-generally-available-for-github-hosted-runners/
• Hosted runner groups and policies: https://github.blog/changelog/2026-06-25-more-control-over-your-github-hosted-runners/

[initial-d]

Thanks for the screenshot. One correction to my previous interpretation: the screenshot does not show the job actually running steps yet. It shows that the job has been queued for several minutes and is still at:

Requested runner group: Mobile - iOS
Requested labels: macos-26
Waiting for a runner to pick up this job...

That changes the diagnosis a bit. Since the standard macos-26 label is now being requested and it is still waiting, this is probably not just the old custom label ghe-runner-macOSARM64-os26 being wrong.

I would narrow it down with these checks:

1. Run the same minimal test with no runner group:

jobs:
  route-test:
    runs-on: macos-26
    steps:
      - run: sw_vers
      - run: uname -m

• If this starts quickly, then the problem is inside the Mobile - iOS runner group configuration or capacity.
• If this also stays queued, then the issue is broader: org/enterprise hosted macOS access, billing/quota, or macOS hosted capacity/policy.

2. Ask an org/enterprise Actions admin to open the Mobile - iOS runner group and confirm that it actually contains/permits a GitHub-hosted macOS runner with the macos-26 workflow label. A group can exist and be selectable, but still have no available backing runner that matches the requested label.

3. From the repository view, check Actions -> Runners and copy the label from the runner entry that is available to this repository. GitHub documents this as the safest way to identify the exact workflow label for larger/hosted runners.

4. Because the screenshot shows the job defined at refs/pull/305/merge, also check whether this workflow is running for a pull request from a fork or an untrusted source. Some organizations restrict hosted/larger runner groups for PR workflows for security reasons.

5. If the group is configured correctly and the job remains queued for a long time, I would open the Enterprise Support ticket. Include this screenshot, the run ID/job ID, the Mobile - iOS runner group settings, and the result of the no-group runs-on: macos-26 control test. That comparison will tell Support whether the scheduler is failing at the group-policy layer or at hosted macOS capacity.

Relevant docs:

• Choosing runners / runs-on: https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job
• Running jobs on larger runners / identifying available labels from the repository: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/use-larger-runners
• Controlling access to larger runners with runner groups: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/control-access

[BaraniT-PE]

Thanks for your response @initial-d! and sharing the links as well

I've already tried running with just macos-26 for "runs-on". I'm also retrying it again. It looks the same. PFA below. Also i've tested the other workflow that triggers just the test upon raising pushing the code when the PR is raised and that worked. I suppose, the settings for triggering the pipeline it looks correct to me.

It looks like it could be one of these as you mentioned above

"Ask an org/enterprise Actions admin to open the Mobile - iOS runner group and confirm that it actually contains/permits a GitHub-hosted macOS runner with the macos-26 workflow label. A group can exist and be selectable, but still have no available backing runner that matches the requested label."

Our config is related to macos-26. But i've also tried macos-latest and others. But no change.

If the above is not the case, then it would lead me to raise an Github Enterprise ticket

Regards,
BT

[initial-d]

Thanks, the new screenshots make this much clearer.

The most important one is the run with no runner group:

Requested labels: macos-26
Waiting for a runner to pick up this job...
All GitHub-hosted runners with label [macos-26] are busy.

At that point I would stop treating this as a YAML syntax, PR trigger, or custom-label problem. If runs-on: macos-26 alone produces that message, GitHub is finding the label, but your org/account has no currently available hosted macOS capacity for that label.

The runner-group case may still matter for your final workflow, but it is probably not the first issue anymore, because the same queueing happens without Mobile - iOS in the selector.

I would ask the org/enterprise Actions admin to check these specifically:

1. Current running and queued macOS jobs across the organization/enterprise, not just this repository.
2. The macOS job concurrency limit for the org/enterprise. GitHub documents macOS as a separate concurrency limit, and the macOS limit is shared across standard GitHub-hosted runners and GitHub-hosted larger runners.
3. Any runner-group concurrency policy for Mobile - iOS if that group is used for the production workflow.
4. Billing/quota or enterprise policy that may block additional hosted macOS jobs.

One small caveat on the other workflow that worked: if that test workflow used ubuntu-latest or another non-macOS runner, it only proves that the PR trigger and workflow permissions are OK. It does not prove macOS capacity is available. The useful control test would be a tiny workflow using runs-on: macos-26 only, which your screenshot already shows is hitting the hosted macOS busy/concurrency path.

If your admin does not see any macOS jobs consuming the limit, then I think an Enterprise Support ticket is the right next step. I would include:

• the run ID/job ID for the pure runs-on: macos-26 test
• the screenshot showing All GitHub-hosted runners with label [macos-26] are busy
• current org/enterprise macOS concurrency settings or runner-group settings
• whether any other macOS jobs were running at the same time

That should let GitHub Support distinguish between a real concurrency saturation case and a scheduler/capacity-state issue.

Reference: https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners

[BaraniT-PE]

Thanks for your response @initial-d. I've verified few on my end where the maximum concurrency limit is set to 10 and no one else is using macos-agent at this point of time.

so that might lead to any one of these based on the above conversation

• Any runner-group concurrency policy for Mobile - iOS if that group is used for the production workflow.
• Billing/quota or enterprise policy that may block additional hosted macOS jobs.
• Ask an org/enterprise Actions admin to open the Mobile - iOS runner group and confirm that it actually contains/permits a GitHub-hosted macOS runner with the macos-26 workflow label. A group can exist and be selectable, but still have no available backing runner that matches the requested label.
• there is at least some macOS capacity available for that route

One more thing to confirm, is there anything to do with the environment added below? or by any chance if it restricted due to co-pilot review comments on the PR.

jobs:
  ios-qa-build:
    name: Build iOS QA (Fastlane Match)
    runs-on: macos-26
    timeout-minutes: 60
    environment: qa

[initial-d]

Thanks for checking that. A few clarifications that may help separate the remaining possibilities.

First, environment: qa can block a job, but usually in a different way. If the qa environment has required reviewers, a wait timer, deployment branch restrictions, or a custom deployment protection rule, the job should be waiting on that environment/deployment protection step before it gets the protected environment access. I would normally expect the UI to show an environment approval/protection message, not:

All GitHub-hosted runners with label [macos-26] are busy

So I would test the environment separately instead of assuming it is the cause.

I would use this exact control workflow first:

name: macos-route-test

on:
  workflow_dispatch:

jobs:
  macos-route-test:
    runs-on: macos-26
    timeout-minutes: 10
    steps:
      - run: sw_vers
      - run: uname -m

Important details for this control test:

• no environment: qa
• no Mobile - iOS runner group
• no PR trigger
• no Fastlane/secrets/setup steps

If this still shows All GitHub-hosted runners with label [macos-26] are busy, then the issue is almost certainly outside this workflow file: hosted macOS concurrency/capacity, billing/quota, or enterprise/org policy. In that case I would open the Enterprise Support ticket and include this minimal run as the clean repro.

If the control workflow starts successfully, then add the pieces back one at a time:

1. Add environment: qa. If it waits now, check the qa environment protection rules: required reviewers, wait timer, deployment branches, or custom protection rules.
2. Add the Mobile - iOS runner group. If it waits now, check that group's hosted runner access/concurrency policy.
3. Move it back to the PR trigger. If it waits only for PRs, check whether the PR is from a fork/untrusted source or whether the org restricts hosted/larger macOS runners for PR workflows.

On the Copilot review comments question: Copilot PR review comments themselves should not restrict runner scheduling. They are just PR review/comment activity. The only related thing I would check is whether there is a separate Copilot/PR-review workflow consuming macOS runners, or whether the PR is subject to an Actions approval policy. But that would still be separate from Copilot comments themselves.

Also, when you say no one else is using macos-agent, make sure the admin is checking all GitHub-hosted macOS jobs across the org/enterprise, not only that named runner/group. GitHub documents macOS hosted jobs as having a separate concurrency limit, and that macOS limit is shared across standard GitHub-hosted runners and GitHub-hosted larger runners.

References:

• Environment protection rules: https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
• GitHub-hosted runner concurrency limits: https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners

[BaraniT-PE]

I did the control workflow test and still it's same and so I suppose as mentioned above, it could be one of these hosted macOS concurrency/capacity, billing/quota, or enterprise/org policy. I'll request to create a Github Enterprise ticket to proceed. In case if you want me to check anything that you think could be the issue, please advise

Regards,
BT

[initial-d]

Your control workflow has now removed the custom label, runner group, and protected environment from the equation, yet the standard runs-on: macos-26 job still remains queued. I do not think there is another repository-level YAML change worth testing.

Opening an Enterprise Support ticket is the correct next step. Include the organization/enterprise name, affected repository, run IDs and timestamps, requested label (macos-26), the queue message, current macOS concurrency usage, and confirmation that the minimal workflow_dispatch control job behaves the same way. GitHub can then inspect hosted-runner allocation, billing/quota, policy, and scheduler telemetry that community members cannot access.

I would leave the minimal control workflow available until Support responds, but avoid repeatedly re-running it because the results are already consistent.

[BaraniT-PE]

@initial-d My admin pointed this one that mac-os runners are not available for sub domains. I saw that too. We are running with a subdomain. If this is the case, what should we do? Please advise

[mattcj7]

I'm having similar issues and appears to be an expired credential on GitHub's end.

Title: pipelines.actions.githubusercontent.com serves expired TLS certificate; self-hosted runners cannot connect

Since 2026-07-19 23:12 UTC, our self-hosted GitHub Actions runner has been unable to reconnect. It reports an SSL connection failure and all jobs targeting that runner remain queued.

From the runner host, pipelines.actions.githubusercontent.com resolves through the system resolver, Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) to 13.107.42.16. Direct TLS validation consistently receives:

• CN: *.actions.githubusercontent.com
• notAfter=Jul 19 23:05:54 2026 GMT
• verification error: certificate has expired

The host clock is NTP-synchronized, and github.com plus api.github.com validate successfully from the same machine.

Can GitHub confirm whether this Actions CDN endpoint is affected and restore a valid certificate?

[BaraniT-PE]

I suppose this is different from what I'm facing.

[initial-d]

If your admin means that GitHub-hosted macOS runners are not available for your Enterprise/subdomain tenant, then there probably is no workflow YAML change that can fix this.

The control test already proved the important part: even a minimal job with only:

runs-on: macos-26

remains queued. That means the label is recognized, but no hosted macOS capacity is being allocated to that repository/org route.

I would separate the next steps like this:

1. Ask the Enterprise/Actions admin to check the repository's available runners page and confirm whether any GitHub-hosted macOS runner labels are actually available to that repo/org. GitHub's docs say users with repo write access can view the runners available to a repository from Actions > Runners.

2. If macOS hosted runners are not supported/enabled for that subdomain/enterprise setup, open an Enterprise Support ticket and ask GitHub to confirm the exact limitation and whether hosted macOS can be enabled for your tenant. Include the minimal workflow run ID, requested label macos-26, timestamps, and the admin's finding.

3. If GitHub confirms hosted macOS is unavailable for that environment, the practical workaround is to use a self-hosted macOS runner controlled by your org, or move the iOS/macOS workflow to an org/repo context where GitHub-hosted macOS runners are available. For non-Xcode jobs, split them onto Linux/Windows hosted runners so only the iOS build/signing job needs macOS.

I would also treat the expired TLS comment above as a separate issue unless your logs show the same certificate failure. Your symptom so far is a GitHub-hosted macOS allocation/availability problem, not a self-hosted runner connectivity problem.

Relevant docs:

• GitHub-hosted runner labels and macOS runner types: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
• Choosing a runner / runner labels: https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job
• Self-hosted runners if hosted macOS is unavailable: https://docs.github.com/en/actions/concepts/runners/self-hosted-runners