Self hosted runners in the organization are not visible to both public and private repositories if they are in a custom runner group

[estellise-yukihime]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Summary

I created a self-hosted runner in the organization for a personal project and registered it under a custom runner group instead of "Default.", but the runner is not visible in the "Runners" tab of the public and private repository under the organization. It only becomes visible when I move it back to the "Default" group.

Steps to reproduce

1. Create an organization-level self-hosted runner.
2. Create a new runner group (e.g., named "Sample") with:
   • Repository access: All repositories, with Allow public repositories
   • Workflow access: All workflows
3. Move the runner into this new group.
4. Go to a public repo → Settings → Actions → Runners.
5. Go to a private repo → Settings → Actions → Runners.

Expected behavior

The runner should be visible in both private and public repository in the Runners tab, since the group grants access to all repos (including public).

Actual behavior

The repos show "There are no runners configured." The runner is only visible once I move it back to the Default group.

What I've tried

• Created a second custom group with the same "All repositories + public" settings, same result.
• Created a third custom group scoped to Selected repositories, same result, runner still not visible.
• Confirmed the runner shows as Idle/Online in the org-level Runners page.
• Only reverting the runner back to the Default runner group makes it visible.

This is the runner group I created with their access

This is the runner tab in public and private repository

Public repository:

Private repository:

I don't know if I'm missing something, I want to ask the community first before I want to write a ticket for this as a bug to GitHub.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[kartik99917]

I’m seeing the exact same behavior, so I don’t think this is an isolated issue.

I set up an organization-level self-hosted runner and assigned it to a custom runner group with access to All repositories and Allow public repositories enabled. According to the configuration, the runner should be available to every repository in the organization.

However, the runner only appears when it’s assigned to the Default runner group. As soon as I move it to any custom runner group, it completely disappears from both public and private repositories, even though the group permissions clearly allow access.

Here’s everything I’ve already tried:

• Created multiple custom runner groups from scratch.
• Verified that All repositories is selected.
• Enabled Allow public repositories.
• Tried both All workflows and restricted workflow access.
• Removed and re-registered the runner.
• Restarted the runner service and confirmed it was online.
• Deleted and recreated the runner group.
• Tested with both newly created and existing repositories.
• Waited for synchronization in case it was a caching or propagation delay.
• Confirmed the runner appears immediately after moving it back to the Default group.

None of these steps resolved the issue. It really looks like custom runner groups are not exposing organization runners correctly, despite the configured permissions.

If anyone has found a workaround or if the GitHub team can confirm whether this is a known bug, that would be very helpful. At the moment, the only configuration that consistently works is using the Default runner group, which defeats the purpose of creating custom runner groups.

[DhruvalAnandkar]

Hi @estellise-yukihime! This really looks like a UI limitation rather than an actual access problem so you haven't missed anything obvious.

The Settings -> Actions -> Runners page at the repository level can sometimes be unreliable for displaying organization-level runners. Usually, it is just a display issue in that specific settings view even when your permissions are configured perfectly.

The good news is that the runner likely still has access! Here is how you can verify it:

1st Check the dedicated Runners page: github actually added a separate page to solve this visibility issue. Go to your repository-->click the main Actions tab at the top (not Settings) and look down the left sidebar under "Management" --> Runners. This page lets you explore all available runners for the repo, so your custom group runners should safely show up there.
2nd Run a quick test: it is highly worth just pushing a test workflow with runs-on: self-hosted. Even if the runner is completely invisible in the old settings UI the GitHub routing backend often still knows it's there and will pick up the job.

One quick heads-up on the public repository access: if this runner group was shared down to your organization from a GitHub Enterprise account you actually can't override the "Allow public repositories" setting at the org level that has to be changed in the enterprise settings instead. However, if you created the group directly in the organization (which it sounds like you did!), that checkbox should apply normally.

I hope this helps save you both some time and gets you unblocked! Let me know if the runner picks up a test job when you trigger it. (And if this clears things up, I'd really appreciate it if you could mark this as the answer! )

[orgito1015]

Thanks for the suggestion! I gave it another try after reading your comment.

In my case, the runner is actually able to pick up jobs, so the permissions and routing don't seem to be the problem. What confuses me is the inconsistency in the UI.

When the runner belongs to the Default runner group, it immediately appears under Settings → Actions → Runners for the repository. As soon as I move the exact same runner into any custom runner group (with identical permissions, including access to all repositories and public repositories), it disappears from that page, even though it continues to function.

That makes me think this is either:

• a UI bug,
• an undocumented limitation of custom runner groups, or
• an intentional behavior that isn't clearly documented.

If it's intentional, I'd expect the documentation to mention that repository-level visibility only applies to runners in the Default group. Otherwise, this seems like something GitHub should investigate.

[DhruvalAnandkar]

Hi @orgito1015 and @estellise-yukihime!

That is a really useful data point, @orgito1015! I'm really glad to hear the runner is actually picking up your workflow jobs successfully. Since it is executing jobs perfectly despite being invisible in Settings, that is strong evidence this is a front-end sync or display issue rather than a real permissions blocker.

@estellise-yukihime, have you had a chance to confirm the same thing on your end? Does a quick test workflow with runs-on: self-hosted actually get picked up by your runner, even though it is missing from the repo Settings page?

If it works for you too, then you are definitely dealing with a UI inconsistency or an undocumented limitation on how GitHub populates that legacy settings page for custom groups. At that point, it is highly worth dropping a quick ticket to GitHub Support like you mentioned, just to flag this specific view discrepancy so their engineering team can patch it.

Let us know how the test run goes! (And if this confirms your setup is actually working under the hood, I'd super appreciate it if you could mark this thread as answered!)