GitHub Actions workflow file exists on default branch but is not registered in Actions

[pggithaiga-sudo]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I have a private GitHub repository:

pggithaiga-sudo/NarrativeROI-homepage-redesign-clean

Default branch:
editorial-reliability-rebuild

Workflow:
.github/workflows/editorial-refresh.yml

The workflow file is present on the default branch and is valid GitHub Actions YAML. It contains both schedule and workflow_dispatch.

Current commit:
c2fa9017f4718d1713dec91b94e0b337daeb9357

Workflow blob SHA:
e3a5ab73cdde24ab1c4e402456368bed03181bd9

GitHub has recorded the default-branch push:
PushEvent
2026-10-01T17:01:02Z
refs/heads/editorial-reliability-rebuild

Repository Actions settings are:

• Allow all actions and reusable workflows
• Read and write workflow permissions

The GitHub Code/Contents API can retrieve:

.github/workflows/editorial-refresh.yml

HTTP 200

However the Actions API reports:

GET /repos/pggithaiga-sudo/NarrativeROI-homepage-redesign-clean/actions/workflows

HTTP 200
total_count: 0
workflows: []

and:

GET /repos/pggithaiga-sudo/NarrativeROI-homepage-redesign-clean/actions/workflows/editorial-refresh.yml

HTTP 404

The Actions web UI also shows:

• 0 workflow runs
• no workflow listed in the sidebar
• no "Run workflow" button

The workflow file is visibly present in GitHub Code under .github/workflows/.

A normal default-branch push was already processed after the workflow file was present, and the push successfully triggered the separate Netlify deployment, but the workflow still was not registered.

The repository is private, GitHub Actions is enabled, and the account currently has GitHub Free with 2,000 included Actions minutes; billing shows 10 minutes used and $0 billable usage.

What could cause GitHub's Actions subsystem to fail to register this workflow even though the repository's Contents system can see the file and all repository-side workflow prerequisites appear satisfied?

[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. ⭐

[Jyotir2004]

The key evidence is the Actions API returning total_count: 0.

This is different from a workflow that is registered but failing to run.

GitHub's normal workflow discovery process searches .github/workflows for workflow files and registers workflows from there. The Actions REST API should then be able to list the registered workflow and retrieve it by filename.

What your symptoms mean

You have:

Contents API
.github/workflows/editorial-refresh.yml
→ HTTP 200

but:

GET /actions/workflows
→ HTTP 200
total_count: 0
workflows: []

GET /actions/workflows/editorial-refresh.yml
→ HTTP 404

and the UI has:

no workflow
no workflow runs
no Run workflow button

That strongly indicates the file exists in Git's repository/Contents layer but has not been successfully ingested/registered by the Actions subsystem.

The important distinction is:

Git repository
↓
Contents/Git API sees workflow file
↓
Actions workflow discovery/parser
↓
Registered workflow
↓
Events / schedule / workflow_dispatch
↓
Workflow run
↓
Runner

Your failure appears to be around:

Actions workflow discovery
↓
registration

not at the runner stage.

Why ARC is probably not the cause

ARC/Actions Runner Controller operates on the runner/job execution side.

Your workflow hasn't even reached that stage.

If GitHub's Actions API says:

{
"total_count": 0,
"workflows": []
}

there is no registered workflow for ARC or ubuntu-latest to execute.

So I would not investigate ARC runners first.

Most plausible causes

1. Actions workflow-registration/indexing failure

Given that:

the workflow is on the default branch,
GitHub can retrieve the blob,
a default-branch push occurred afterward,
Actions is enabled,
permissions are permissive,
billing/quota isn't exhausted,
and the Actions API sees zero workflows,

the strongest explanation is an Actions-side workflow discovery/registration problem.

This could be a transient GitHub backend issue, delayed indexing, or an internal failure processing that repository's workflow definition.

This is particularly different from a scheduler outage: the workflow isn't registered at all, so scheduled events aren't even the first failure point.

2. Actions parser rejecting the workflow

There is one thing I would still verify before escalating to GitHub:

"Valid YAML" is not necessarily the same as "valid GitHub Actions workflow."

GitHub performs workflow-specific validation after reading the YAML. For example:

on:
schedule:
- cron: "..."
workflow_dispatch:

must be structurally valid for Actions, not merely syntactically valid YAML.

GitHub documents workflow_dispatch and schedule as supported triggers, and workflow_dispatch requires the workflow to exist on the default branch.

However, given that you say the file has already been validated and GitHub's Code API can retrieve the exact blob, a registration/indexing failure remains a serious possibility.

3. Default-branch metadata inconsistency

You have an interesting detail:

default branch:
editorial-reliability-rebuild

and GitHub recorded:

PushEvent
2026-10-01T17:01:02Z
refs/heads/editorial-reliability-rebuild

If the repository's default branch metadata, ref resolution, and Actions workflow-discovery service were temporarily inconsistent, GitHub could theoretically see the file through Contents while Actions failed to ingest it.

This is another reason your successful push does not prove that Actions processed the workflow.

GitHub specifically states that scheduled workflows run from the latest commit on the default branch, and workflow_dispatch requires the workflow file on that branch.

4. Billing is almost certainly not the explanation

Your:

2,000 included minutes
10 minutes used
$0 billable

doesn't explain this particular symptom.

A minutes/quota problem would normally affect execution, whereas you have no registered workflow object at all.

The workflow-list API returning zero is much more significant.

The best diagnostic now

I'd perform one controlled test:

Create a brand-new minimal workflow on the same default branch:

name: Actions Registration Test

on:
push:
workflow_dispatch:

jobs:
test:
runs-on: ubuntu-latest
steps:
- run: echo "Actions registration test"

Commit it directly to:

editorial-reliability-rebuild

Then immediately check:

GET /repos/pggithaiga-sudo/NarrativeROI-homepage-redesign-clean/actions/workflows
Interpretation

If you still get:

{
"total_count": 0,
"workflows": []
}

then you have a repository-level Actions registration problem, not a cron problem, ARC problem, secrets problem, runner problem, or editorial-refresh.yml application problem.

If the new workflow appears, then investigate the specific editorial-refresh.yml definition.

One caveat about your API test

I couldn't independently inspect this private repository through the GitHub connection available to me—the connection returned 404 Not Found for the repository—so I'm treating the API responses and commit/blob SHAs you supplied as your observed evidence rather than independently verified results.

Bottom line

Your evidence points to:

The repository's Git/Contents layer recognizes .github/workflows/editorial-refresh.yml, but the GitHub Actions service does not currently have a registered workflow object for it.

That makes Actions workflow discovery/registration or an Actions backend inconsistency the primary area to investigate.

It is earlier in the pipeline than ARC, scheduling, or runner execution.

If the minimal push + workflow_dispatch registration test also produces total_count: 0, I would escalate it to GitHub Support as an Actions workflow registration/indexing failure, including the repository, default branch, commit SHA, workflow blob SHA, the two API responses, and the timestamp of the successful default-branch push.