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.

[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 https://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.