GitHub Actions' REST API now returns "2,500+" instead of an exact number once a workflow-run query matches more than 2,500 records. The change rolled out on September 25, 2026 to both github.com and GitHub Enterprise Cloud, according to GitHub's changelog entry announcing the change. GitHub filed it under "Improvement." If your dashboard, alerting script, or internal tool reads the total_count field from the "List workflow runs for a repository" endpoint and compares it against a number, it's worth checking now: past 2,500 matches, GitHub reports "2,500+" instead of an exact figure.
What changed on September 25, 2026
GitHub's stated reason is blunt: queries that retrieve more than 2,500 records frequently time out, and the count that comes back is however many records the search found before the timeout, not the true total. Rather than keep returning a number that might be wrong, GitHub now shows "2,500+" for any workflow-run query where the match count crosses that line. The underlying data doesn't change. Pagination, filtering, and the runs themselves work exactly as before. Only the reported total changes shape once a query crosses that line.
Which queries are affected
The cap applies to queries filtered by workflow, event, status, branch, or actor, the fields most dashboards already use to slice run history. A query for every run of a specific workflow, every failed run on a branch, or every run triggered by a given actor can cross 2,500 matches on an active repository, especially one with several workflows firing on every push. Smaller, already-narrow queries (a single day's runs, a single pull request's checks) rarely get close to the threshold and keep returning exact counts as before. GitHub's changelog names these filtered queries specifically; it doesn't say whether an unfiltered query runs into the same cap, so don't assume one is safe just because no filter is applied. The size of your repository's run history is what decides whether you ever see "2,500+."
Why your dashboard or script just broke
total_count used to report an exact number every time. Past 2,500 matches, GitHub now reports "2,500+" instead, and any code that treats the field as an exact total (a threshold comparison, a value written straight into a numeric database column) needs checking. None of this shows up in a review of the workflow file itself. The break lives wherever the response gets consumed, which for most teams is a script or dashboard nobody has opened since the day it was built.
How to fix scripts and dashboards that read total_count
1. Find every place your code reads total_count from workflow-run queries
Search every repo, script, and dashboard config for total_count alongside /actions/runs. Include internal tools and cron jobs, not just the obvious CI dashboard. Check every consumer, not just the one that broke first; the same field usually feeds more than one script.
2. Add a created date-range filter to narrow queries under 2,500
GitHub's own recommendation is to narrow the query with a date range so the match count stays under 2,500 and you keep getting an exact number. The workflow-runs endpoint accepts a created parameter that filters by a date-time range; use it to scope a query to, say, the last 30 or 90 days instead of a repository's entire history. A narrower window costs nothing if the metric you actually care about (this week's failure rate, this month's run volume) was never a lifetime total to begin with.
3. Rebuild any "total runs" metric that needs an exact count past 2,500
If a metric genuinely needs a lifetime count above 2,500, total_count can't give it to you anymore, and pagination won't fill the gap either: a filtered query still tops out at 1,000 results. Split the query into created date windows that each stay under the limits and sum the counts, or maintain a running counter in your own database that increments as new runs complete. Either approach costs more calls than reading one field, but it gets you an exact number past the threshold.
4. Re-test alerting or SLA scripts that compare total_count against a numeric threshold
Any alert that fires when total_count crosses a set number needs a manual test now, not just a read-through. Run it against a query you know returns "2,500+" and confirm it fails safely instead of throwing an unhandled error or silently evaluating false forever. A script that has quietly stopped alerting is worse than one that crashes loudly, because nobody notices until something else goes wrong first.
What the REST API docs say about pagination and filters
The "2,500+" display sits on top of pagination limits that already existed. The workflow-runs endpoint's own documentation caps per_page at 100 (default 30) and returns up to 1,000 results when you apply filter parameters, regardless of how high total_count climbs. Available filters include actor, branch, event, status, check_suite_id, head_sha, and created, the last of which takes a date-time range rather than a single value. status alone accepts more than a dozen values, from completed and queued to action_required and stale. None of this pagination behavior is new. What's new is only the number GitHub shows you before you start paging.
Two other GitHub Actions changes are worth auditing alongside this one. GitHub Actions Node 20 removed: what breaks & the fix covers the Node 24 runtime cutover that landed two days earlier, and GitHub proof of presence: what it locks and who gets it covers an admin change from the same stretch of changelog entries. Both are listed in Platform and language release notes: what breaks and what to fix. If nobody on the team owns auditing changes like these as they land, the DevOps engineer who owns this kind of maintenance is worth hiring before the next one catches you off guard.
FAQ
Does the "2,500+" change affect every GitHub Actions API query?
No. GitHub's changelog names workflow-run queries filtered by workflow, event, status, branch, or actor specifically. It doesn't say whether an unfiltered query is exempt from the same cap, so don't assume one is safe by default. Small repositories, narrow date ranges, and any filter that naturally returns fewer than 2,500 matches keep getting exact counts regardless. The cap only kicks in once a query would otherwise need to count past 2,500 records.
What is the maximum number of workflow runs the API will paginate through?
Pagination itself is capped at 1,000 results when you use filter parameters, separate from the "2,500+" display cap on total_count. You can request more with per_page and page, up to that 1,000-item ceiling, but you can't page through more than 1,000 actual run records in a single filtered query regardless of how high the reported total goes.
How do I get an exact workflow-run count above 2,500?
Narrow the query with a created date-range filter until the match count drops under 2,500, and GitHub reports the exact number again. If you need a running lifetime total that will eventually exceed 2,500, split the query into date windows that each stay under the limit and sum the counts, or track the total yourself in your own database as runs complete; pagination itself is capped at 1,000 results per filtered query, so it can't fill that gap on its own.
Does this affect the GitHub Actions UI, the GitHub Actions REST API, or both?
Both. GitHub's changelog title covers query results in "the GitHub Actions API and UI," and the "2,500+" display shows up whether you're looking at a repository's Actions tab in the browser or reading total_count from an API response.