[Bug] GitHub API - List workflow runs returns 0 runs even though there are runs

[dominicroessner]

Trying to use the API or the UI to get workflow runs for a specific branch returns no results.

In the UI, when going to Actions on a repo and filtering by branch shows an error message on top of the page We are having problems searching workflow runs. The results may not be complete.

Using the API and the following endpoint:

curl --location --request GET 'https://api.github.com/repos/{owner}/{repo}/actions/workflows/main.yml/runs?branch=my-branch&per_page=1' \
  -H "Authorization: token <my token>" \
  -H "Content-Type: application/vnd.github.v3+json" \

Returns the following even though I can clearly see the run through the pull request UI, or when in the Actions UI and not filtering by branch.

{
  "total_count": 0,
  "workflow_runs": [
]

}

[ericmatte]

I have the same problem on my side in a private repository.

If you call https://api.github.com/repos/{owner}/{repo}/actions/workflows/main.yml/runs without the branch parameter, you can clearly see the runs from that branch in the list.

Also, it seems to work when filtering on older branch, but not on the new ones.

I tried using curl and the octokit from @actions/github.

[alexcampbell86]

Am seeing a similar issue, i need the status=in_progress parameter for one of my workflows. Without the filter I can see several workflows with a status of in_progress. The filter for status=completed works as expected. But status=in_progress always returns:

{
  "total_count": 0,
  "workflow_runs": [
]

}

[torbjornvatn]

I get this as well, but only for branches created the last couple of days.
If I use the branch= filter for one of my older branches, it works.

[gat-bryszard]

Same problem although with status= filter. Described it here - List workflow runs API not detecting "in_progress" builds - #5 by gat-bryszard

[torbjornvatn]

Seems like it’s resolved now

[hakim-dc]

what version you are using pls ?

[leofang]

This issue has come back. Not resolved.

[billyvg]

I have a public repo where this is happening. If I list all workflow runs for a workflow without any query parameters, it returns fine. But if I try to query with a parameter, I always get a 404. Currently using the GH CLI, but also happens in GH Actions.

[apconole]

I have a similar problem - for example:

curl -i -s -S -H “Accept: application/vnd.github.v3+json” “https://api.github.com/repos/ovsrobot/ovs/actions/runs?branch=series_294442”

vs.

curl -i -s -S -H “Accept: application/vnd.github.v3+json” “https://api.github.com/repos/ovsrobot/ovs/actions/runs?branch=series_294634”

I am not sure how to proceed

[BetimShala]

it’s still happening, how is this resolved?

[astrelya]

Hello,

I have the same issue on one of my repo, when I list all runs I can see the one I’m looking for :

“https://api.github.com/repos/astrelya/REPO/actions/runs”
(I find in the run : head_branch=XXX)

but when I specify the branch

“https://api.github.com/repos/astrelya/REPO/actions/runs?branch=XXX”

I get total_count: 0.

EDIT : when I request with parameter actor=astrelya I don’t get all of the runs neither.
EDIT 2 : I checked on other repos, and It seems that I can’t get any run post April 10th by request with parameters.

Thanks.

[ivailop]

In the GitHub UI, simply filtering (e.g. branch: master) Actions returns empty list with a pink-error banner:

We are having problems searching workflow runs. The results may not be complete.

[davinchia]

We are also seeing this. We are getting inconsistent results from filters. An existing query that has not been modified for months is now returning stale data.

[kalski]

We also have the above described problems when using filters.

This bug is marked as solved but it seems to be again open. Is there a way to mark it accordingly here ?

[flipace]

Same here, this started to happen somewhen in the past few days, and caused one of our jobs to go rogue and use up all of our “free” GH action minutes during the night until we could stop it 😭

[bitops]

Also seeing this issue when querying the workflow runs with a branch name specified. Thus far it has not been working for 3 days.

[mimartin12]

This is still affecting us, not resolved.

[mimartin12]

I am also having issues still with this endpoint.

When filtering for the branch with ?branch=branch-name I receive

{
  "total_count": 0,
  "workflow_runs": [
]

}

However, when I just call the /run endpoint, I can see that the branch that I was filtering for is included in that list. Additionally, there is a red banner on our Github projects when filtering for branches in the actions menu.

We are having problems searching workflow runs. The result may not be complete.

[davinchia]

This is what Github support told me:

On Monday, the search functionality with Actions experienced a breaking error. A fix was implemented soon after the break to address the underlying issue, but now search is being re-indexed which can take up to a few days. While this is happening, un-filtered searches for all workflows and specific workflows are working as expected still, but any filtering on those results is broken at this time.

This is impacting filtering both through the UI and API.

We are closely tracking the re-indexing, and I will follow-up here again once it has completed and search is functioning as expected. In the meantime, please let me know if there is anything further you would like to discuss. Thanks!

[terrabitz]

+1 to this issue

We’re still seeing issues when filtering by branch. We see no results returned in our recently-made repository.

[m0ppers]

same here:

curl -u m0ppers:$PAT "https://api.github.com/repos/$OWNER/$REPO/actions/workflows/$ID/runs?page=1&per_page=5&branch=master" | jq '.workflow_runs[] | {created_at: .created_at, head_branch: .head_branch}'

returns an 8 day old run as first entry

without branch I get the newer results.

I am using GitHub - dawidd6/action-download-artifact: A GitHub Action to download an artifact associated with given workflow and commit or other criteria to download a terraform plan artifact from a separate workflow and it currently downloads a stale terraform plan and apllying doesn’t work

🙃

[rajbos]

This issue is still present, we jus ran into it with filtering on the action runs:

Get all results:

https://api.github.com/repos/owner/repo/actions/runs
Returns 36 results:

Get only completed:

https://api.github.com/repos/owner/repo/actions/runs?status=completed
Returns 22 results:

Get everything that is waiting:

https://api.github.com/repos/owner/repo/actions/runs?status=waiting

[chiragvidani]

@rajbos We are also facing a similar issue for the last 3 days. status filter was working previously, but it is breaking now.

• When adding status filter in API request, its returning 0 runs.
  

• Without adding status filter in API request, its returning n runs.
  

Can anyone please guide where to report this issue? Also, we are having enterprise license.

[Lance-Simeon]

I started seeing it this week as well, in my case it's when filtering by status.

[viveklak]

Seeing the same issue as mentioned in https://github.com/orgs/community/discussions/24626#discussioncomment-5690204 - specifically for filters with status set to waiting. This seems to have started around April 20th.

[bkgrant]

Agreed this has recently become an issue for all queued or in_progress status queries

[amadosdiop]

Hello,
I have the same issue also with filter : status=pending

[metas-ts]

same here, with status=completed i do get my workflow-run (and i see in the JSON-response that it is completed ) when i actually drop the status=completed from my query

[metas-ts]

update: I opened a ticket and got a reply that they identified and addressed a problem with filtered API-results
So they currently expect filtered&unfiltered API-results to be in sync

[abhijit-hota]

Hey @metas-ts Were you using the created filter by any chance? Curious as to how you fixed it. I'm facing a similar issue.

[ethitter]

I'm experiencing a similar issue. I'm trying to collect monthly usage for a specific job, but requests for workflow runs for page 11 or higher return zero results; that's despite the total_count showing that there should be results well beyond page 10. I've worked around this by querying for smaller date ranges to ensure that the result set is fewer than 1,000 entries.

[abhijit-hota]

Facing a similar issue.

I've worked around this by querying for smaller date ranges to ensure that the result set is fewer than 1,000 entries.

Unfortunately, I need workflow runs from a specific date.

[abhijit-hota]

I'm facing an issue with using created and status=completed filters together. The results are only correct the first 10 pages after which it doesn't return anything.

I opened a bug report here: #86766

[KarenJoseph]

Same issue with check runs api
https://api.github.com/repos/${{ github.repository }}/commits/$COMMIT_SHA/check-runs

where some checks regardless of their state are not listed
while using the ?check_name=name parameter returns the result

all results are in one page

[theyoprst]

Looks like GitHub has broken this completely, it is reproduced in 100% of cases :-(
https://github.com/orgs/community/discussions/194141

[sxlijin]

We are seeing this again on 2026-09-04, specifically with the server-side status=success filter. The endpoint returns HTTP 200 and valid JSON, but the result set is intermittently stale or incomplete.

Affected query:

GET /repos/BoundaryML/baml/actions/workflows/203063461/runs?branch=canary&event=push&exclude_pull_requests=true&per_page=100&status=success

This is also the query generated by:

gh run list --repo BoundaryML/baml --workflow ci.yaml --branch canary --event push --status success --limit 100

We tested the filtered endpoint and the same endpoint without status=success back-to-back 10 times, sleeping 60 seconds between each pair. For the unfiltered response we applied conclusion == "success" locally.

Results:

• Filtered query was wrong in 3/10 samples.
• Unfiltered query plus local filtering was correct in 10/10 samples.
• The correct filtered response reported total_count=814 and returned the current successful run first.
• One bad filtered response reported total_count=742 and returned a page spanning 2026-08-25 back to 2026-07-29.
• Two other bad responses reported total_count=400 and 530, returned pages reaching back to May/June, and omitted the newest successful run.
• The unfiltered response consistently reported total_count=1338, the same recent page bounds, and the same newest successful candidate in all 10 samples.
• Every bad filtered response was HTTP 200 with valid JSON, so retrying only transport/API errors does not catch this.

[dslatkin]

Yeah, we're having the same issue, first noticed on August 27 where we didn't get more than a month of daily workflow runs returned. This was coincidentally timed around a GitHub Actions outage. Then it's happened a few more times the past couple weeks.

We've recently come to the same conclusion independently that in the meantime we need to use gh run list without the status filter applied. 🫩

Wouldn't be surprised based on this comment if the results just aren't trustworthy/deterministic in general, and that's never been changed or fixed.

[sxlijin]

FWIW, I made the original comment using an LLM while I was investigating this (it was the cause of a flaky release pipeline for us), but we saw the flakiness over all of August. I didn't bother doing a rigorous historical analysis, so that's an anecdata claim, but we've now been running for the past week without the server-side filtering, having the automation cross-check the commit history to verify query completeness, and haven't seen issues.

If I put on the hat of someone at GH drowning under scaling bugs (and the ridiculous Azure infra migration), then it makes a lot of sense why the server-side filtering isn't high priority for them: the most user-visible features of Actions are (1) the ability to dispatch actions and (2) the UI for browsing them. Consequently, the read query capabilities that are most important for (2) are the ability to fetch mostly consistent, unfiltered, most-to-least-recent workflow runs (consistent as in CAP) for recent runs (past 1h, past 6h, past 48h).

Similarly, because the UI for browing Actions results is much more core to GH as a platform offering, then I trust the backend that backs that UI more than I trust gh run list filters (I've run into other issues where we'd rather use the API directly instead of the gh CLI)

So I'd put money on there being some eventual consistency property of the underlying backend/query system that appears strongly consistent for the unfiltered queries - maybe because of the ordering guarantees or lack of filtering, maybe because of the complexity that would have to get added to the storage/query engine in the cache layers - combined with weak business priorities that mean that gh run list with filters just isn't trustworthy.

I'd honestly advocate for them removing those features, or changing them to be implemented as client-side filtering with how broken it is... but that's a different story.

[leofang]

We're seeing the same issue (NVIDIA/cuda-python#2975) and it breaks our existing workflows that rely on correct filtering for decision making.