Actions REST API: listWorkflowRuns returns stale results (sometimes weeks old) on high-volume repos

[dsibilio]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

Describe the bug

GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs (and the repo-wide
GET /repos/{owner}/{repo}/actions/runs variant) intermittently returns a stale result set on a
repository with a high volume of workflow runs. The same exact query, called seconds to minutes
apart with no other change, returns a materially different "most recent" run and a different
total_count, with the stale response sometimes landing weeks behind the true most recent run.

This reproduces both with and without the status filter, so it isn't specific to that parameter.

Steps to reproduce

1. On a repository with thousands of workflow runs for a given workflow, on a branch that receives
   many pushes a day, call:
   GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs?branch={branch}&event=push&status=success&per_page=1
2. Repeat the identical call a few seconds to a few minutes later.
3. Compare total_count and workflow_runs[0].head_sha / created_at between the two responses.

Note: this seems to happen a LOT more frequently when run in GitHub actions, e.g. via github-script invoking:

github.rest.actions.listWorkflowRuns({
            owner: context.repo.owner,
            repo: context.repo.repo,
            workflow_id: workflowId,
            head_sha: commitSha,
            event,
        });

Actual behavior

Observed both of the following independently:

• Two consecutive calls to the same query, ~11 seconds apart, returned total_count: 1942 with the
  top run dated ~3 weeks old, then total_count: 4265 with the top run dated seconds ago. No new
  workflow runs could plausibly account for that count jump in that time window.
• A real production workflow run consumed this endpoint (via actions/github-script /
  @octokit/plugin-paginate-rest, with full HTTP debug logging enabled) and picked a specific commit
  as "the most recent successful run" that was in fact ~3.5 weeks and several hundred commits behind
  the actual most recent successful run on that branch at that exact moment. Re-running the identical
  query moments later, and a time-bounded reconstruction using the created filter to pin the exact
  same instant, both showed the true most recent successful run should have been returned instead.

This occurred both with status=success set and with it omitted (filtering client-side on
conclusion instead), so dropping that particular filter is not a workaround.

Expected behavior

The endpoint should reflect the actual current state of workflow runs.
The endpoint should NOT return data that is stale by several weeks.

Impact

This endpoint is a documented, commonly recommended way to find "the last successful run on a branch"
for CI/CD tooling. On a busy repo, staleness of this magnitude causes CI to silently use a wildly
outdated comparison base, with no error surfaced, since the query itself returns a normal-looking
(but stale) 200 response.

Additional context

• Somewhat related community reports of more or less similar symptoms on the same endpoint family: [Bug] GitHub API - List workflow runs returns 0 runs even though there are runs #24626, Github REST API: in_progress status is returning no workflow runs when there are runs in progress #53266, Failing badge status for passing runs and filters not working correctly #24986.

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

[beenish-majeed]

Hi,

The behavior you described does look more like an API-side consistency issue than a problem with the status filter, especially since you reproduced it with the filter both enabled and omitted.

One thing I’d try as a diagnostic is to constrain the request with created (and, where applicable, head_sha) and compare the returned run against the repository’s Actions UI or a direct run lookup. GitHub documents both filters for the workflow-runs endpoint, so this can help determine whether the stale result is tied to the broad run listing rather than the workflow data itself.

For production tooling, I’d also avoid assuming that the first item from a single broad query is always the definitive latest successful run. If an older run would be dangerous as a comparison base, validating the returned run before using it and retrying when the result is inconsistent would be a safer approach.

Given that you have a reproducible example with full request/response logging and a large discrepancy in total_count, I think this is worth keeping as a GitHub API bug report. The timestamps, request parameters, response IDs/counts, and affected repository/workflow would be especially useful to GitHub when investigating it.

[dsibilio]

We did try something along these lines already: instead of the broad listing, we switched production to a head_sha-scoped query per commit (walking local git history and checking one commit at a time instead of listing/sorting all runs). In our testing so far that narrower, single-commit query has been consistent every time we've checked it, while the broad listing kept flip-flopping. Not conclusive after just a handful of checks, but it's a meaningfully different access pattern (point lookup vs. list+sort), so it's encouraging. However it's not really a valid solution for our use case / would require flipping the logic in a way that is far less efficient.

On "validate the returned run before using it": that's actually the crux of why this is tricky to defend against. The stale response isn't malformed or inconsistent internally, it's a normal-looking single run object that matches everything in the query (right branch, right event, right status), it's just not the most recent one. There's nothing in that response itself that flags it as stale, so validating "does this response look sane" doesn't catch it. The only way we found to catch it was cross-checking against a completely different query (the head_sha lookup) or against git log, not by inspecting the response more closely.

The timestamps, request parameters, response IDs/counts, and affected repository/workflow would be especially useful to GitHub when investigating it.

The current repro is related to a private repository so it won't be valuable sharing most of these, hopefully it should be trivial to repro on other, public repositories when someone from GitHub starts looking into this.

[beenish-majeed]

That's a really useful distinction. The fact that the "head_sha" point lookup is consistently correct while the same broad list query can return a much older run suggests that the issue is specific to how the listing endpoint is retrieving or ordering its result set, rather than the individual workflow run records themselves.

You're also right about the validation point. Since the stale run is a perfectly valid response that matches the branch, event, and status filters, there isn't an obvious signal in the response itself that would reveal that it's stale.

I think that makes the bug report much stronger: the same query can return materially different result sets within seconds, while the stale response is otherwise completely valid. If this can also be reproduced on a public repository, having the raw JSON responses side by side would make the discrepancy especially clear for GitHub's investigation.

[faihsalfariha-ux]

That's a really useful distinction. The fact that the "head_sha" point lookup is consistently correct while the same broad list query can return a much older run suggests that the issue is specific to how the listing endpoint is retrieving or ordering its result set, rather than the individual workflow run records themselves.

You're also right about the validation point. Since the stale run is a perfectly valid response that matches the branch, event, and status filters, there isn't an obvious signal in the response itself that would reveal that it's stale.

I think that makes the bug report much stronger: the same query can return materially different result sets within seconds, while the stale response is otherwise completely valid. If this can also be reproduced on a public repository, having the raw JSON responses side by side would make the discrepancy especially clear for GitHub's investigation.

[pkwarren]

We've started encountering this problem as well starting yesterday and twice today. We've relied on this API returning accurate results for years without issue (preventing costly rebuilds and only rebuilding what changed since the previous successful job run).

Yesterday (around 2026-09-01T23:59Z) instead of returning a head_sha one commit back (as it should), it returned a head_sha 23 commits back. Today in two successive builds (almost an hour apart), instead of returning one commit back it returned commits with a head_sha 75 and 76 commits behind. We've been using gh api "repos/bufbuild/plugins/actions/workflows/ci.yml/runs?branch=main&status=success&per_page=1" to query this data without issue until yesterday.

[n-thumann]

We are experiencing the same issues since a few days:
A request to https://api.github.com/repos/[redacted]/actions/workflows/[redacted].yml/runs?branch=main&status=completed&exclude_pull_requests=true&per_page=100 usually / is expected to respond with

{"total_count": 584, "workflow_runs": [{"id": 33855076135, [...], "created_at": "2026-09-04T08:46:45Z", [...]

but every now and then it we get

{"total_count": 373, "workflow_runs": [{"id": 30330345502, [...], "created_at": "2026-07-28T05:00:29Z", [...]

Note how the "latest" run is suddenly over a month ago instead of a few hours. We've notified GitHub Support.

[rafidahmed01]

This seems to be related to stale/inconsistent results from the listWorkflowRuns API.

The same request can return different results, sometimes showing workflow runs from weeks ago, and even the total_count can change between identical requests.

Using head_sha seems to return consistent results:

github.rest.actions.listWorkflowRuns({
  owner,
  repo,
  workflow_id,
  head_sha: commitSha,
});

However, querying every commit individually is not practical when trying to find the latest workflow run.

Is there a recommended way to reliably get the latest workflow run without using head_sha for every commit? Could this be related to caching or eventual consistency on GitHub's side?

[v-coder247]

Hi @muhammad-a-dev, thanks for participating in GitHub Discussions!

Please note: we’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team. 

You can read our updated Code of Conduct and the announcement for more details.

Please feel encouraged to continue engaging in Discussions as your authentic self though. We appreciate you being a part of the Community 🌟

[arnodb]

Hi, I am experiencing the same issue via the use of http://github.com/dawidd6/action-download-artifact which clearly assumes the returned workflows are returned the most recent runs first.

The parameters of the action are:

• repo
• workflow
• workflow_conclusion (not passed to the API)
• branch

Which leads to https://api.github.com/repos/<...>/<...>/actions/workflows/<...>.yml/runs?branch=<...>

As one stated above, it seems to happen more frequently when queried from GitHub actions. When the API is invoked with curl the error frequency is very low, but is not 0.

[andjak]

We independently reproduced this with sequential requests using Node’s built-in HTTPS client, outside GitHub Actions and without CLI pagination or application caching. Identical first-page requests intermittently returned weeks-old history and substantially different total_count values, omitting successful runs that remained accessible through direct run lookup. One of eight requests reproduced the omission. Separate testing showed that Cache-Control: no-cache and Pragma: no-cache did not reliably prevent it.

[pvorona]

Actions API returns an old successful-run page while a newer eligible run exists

We independently captured this during a production workflow on September 18, 2026. This corroborates http://github.com/orgs/community/discussions/206725.

Request pattern:

GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs

The request filtered by branch, event=push, and status=success, with the default first page (30 results). We recorded the actual response consumed by the workflow, before candidate validation.

At 2026-09-18 19:18:54 UTC, GitHub returned HTTP 200 and total_count=2344. All 30 returned runs were dated September 3–5; the first run was created September 5 at 07:49:48 UTC. An eligible push in the same workflow and branch had already completed successfully on September 18 at 19:09:46 UTC, but was absent. Its individual run record confirmed the matching workflow, branch, event, SHA and successful conclusion.

Expected: the first page should contain the recent eligible run rather than omit it in favor of a result set almost two weeks old.

Impact: our baseline selector rejected all 30 old candidates and fell back to the previous commit. That previous commit happened to have deployed successfully in this occurrence, so no missing delivery was established. The same fallback can be unsafe when the previous deployment failed. An older incident instead selected an old successful ancestor and widened the deployment range.

The response itself establishes the missing recent result; it does not establish GitHub's internal caching or indexing cause. We have the response timestamp, x-github-request-id, candidate metadata and matching newer run details available for GitHub Support privately. Repository identifiers, run IDs and commit SHAs are intentionally omitted from this public summary.

Please investigate consistency of the workflow-run listing endpoint and confirm whether this is a known incident. This is not a request to rerun production workloads.

[zackerydev]

This is staring to hit us everyday and I think it reproduces in the UI as well - if i filter our main workflow by branch:master it shows runs from September 8th, this API i don't think can be relied upon in the UI or the API - hopeful for a fix soon!

[cottsak]

Sep 7, 15:40 GMT+8 is a popular one for us. It's like they're specific cache items that haven't been expired or something. We routinely see almost the same list of stale Runs show up. The count always seems to move tho which is odd. eg, 2,096 workflow run results

[deltanedas]

this happens every time with manual runs for me

[mstein-lc24]

same here, we have to execute our jobs multiple times to get the right data

[mstein-lc24]

Update: I created a support ticket (using paid TEAM-Account) - which was immediately closed. I was told to use the community forum. 👎🏻

Therefore, why do I pay for github, when they refuse to help?!

[trinamic-LH]

I've also encountered this issue [1] and raised this to my colleagues in contact with Github support - lets see if Enterprise support leads anywhere.

[1]: Specifically - repos/{org}/{repo}/actions/runs?branch={branchname}&status=completed REST API endpoint gave me stale results.
On one occasion, querying four consecutive times within ~1 minute gave four different answers:

• The first one was stale by 84 days
• The second one was stale by 13 days
• The third by "just" 23h
• The fourth one finally showed me the latest CICD run I was looking for (3h old)

[acuteaura]

FWIW, we reported this to Enterprise Support mid August, nothing.

[mstein-lc24]

I now implemented a script which retries the request up to ten times (with 5 seconds break) and only stops, when the run is from today. And the last time it really gave me the correct one at the 5th retry.

Crazy solution, but currently works.

[cottsak]

GitHub please just fix this! 😒

[K1ll3rF0x]

Same here. The API has worked reliably for years, until now !

During a scheduled run, the API started returning weeks old run today instead of the newest one (with per_page 1), and breaking our workflows.
We are using actions/github-script v9.0.0

[cottsak]

5 page refreshes just now to get the latest data showing. ffs!

[marcusthelin]

This doesn't seem to be prioritized. It is a problem for us in our NX monorepo. Sometimes it decides to build and deploy all apps even though we just changed one

[ag21qop]

Still happening as of today. Even in the UI, refreshing for the same workflow name search renders a different count every time

[DavidHrbek]

Still happening as of October 6, 2026.

This also impacts AL-Go for GitHub (Microsoft's CI/CD templates for Business Central), which uses
GET /repos/{owner}/{repo}/actions/runs?branch=main&status=completed&exclude_pull_requests=true&per_page=100&created=>...
to resolve "latest build" dependencies between repositories. Stale responses make downstream builds pull
outdated app versions and fail.

Identical requests alternate between returning run_number 2002 (correct) and 1964 (weeks old) as the first
result. Multiple repositories in our organization are affected.

Reported to AL-Go as microsoft/AL-Go#2394. A response from GitHub on whether this is a known incident
and when a fix is expected would be much appreciated.

[acuteaura]

A response from GitHub on whether this is a known incident

Yes.

and when a fix is expected would be much appreciated.

Evidently it is not a priority. It's been almost 2 months since we opened a ticket in our enterprise.

[DavidHrbek]

Yep, it's definitely a known incident, at least within the community. I'm not so sure about GitHub itself. So I would appreciate some reaction from their side.

[acuteaura]

As I said, they have confirmed that they know in tickets.

[cottsak]

Haven't noticed this happening today and yesterday. Anyone else?

[nebuk89]

Hey y'all, sorry for being quiet on this one and thank you all for the engagement.

As @cottsak highlights this should be pretty much eliminated now. We had some issues with over running throughput resulting in timeouts, which in turn resulted in these incomplete results.
We had been doing a bunch of work to scale up to get headroom around this, and had some other changes like https://github.blog/changelog/2026-09-25-changes-to-query-results-in-the-github-actions-api-and-ui/ which helps us with some other optimizations around elastic search.

The net is that we have enough headroom and these timeouts as far as we can see have been driven effectively to zero now, but load keeps going up and we are still working on changes here so if you see a serious regression please feel free to keep adding in here or start a new issue and vote that up <3

[acuteaura]

Right... can you please just return an honest 503 instead of bad data if that happens? It looks like we weren't the only ones using this API to select things to deploy, including that above mentioned Microsoft authored integration. Happy to place this request via our enterprise contact too if that helps.

[deltanedas]

seconding this, APIs timing out should make it clear to the caller rather than lying and giving garbage results with no warning