GitHub changed how GitHub Actions workflow run queries report the number of results in the API and user interface. According to the September 25, 2026 announcement, searches filtered by workflow, event, status, branch, or actor no longer try to provide an exact count when more than 2,500 records match. In those cases, GitHub reports the amount as “2,500+”. Result pagination remains available, and filtered searches still return no more than 1,000 workflow runs per search.
For teams that maintain scripts, integrations, dashboards, or audit routines, the main review point is straightforward: a count above that threshold must no longer be treated as the exact total for the queried set. If an automation needs to find, export, or process a very large number of runs, GitHub recommends narrowing the filters, including by adding date ranges, and performing smaller queries.
What changed in GitHub Actions queries
The change affects workflow run queries in both the GitHub Actions UI and API. GitHub says the previous behavior could produce a number that looked precise but was incorrect for very large searches. Queries retrieving more than 2,500 records frequently timed out while counting and could end up reporting the number found before the timeout rather than the true total.
To reduce that problem, GitHub chose to replace numerical precision with an explicit threshold indicator. Above 2,500 matches, the information means only that more than 2,500 records exist. This prevents consumers from treating a partial count from a large search as an exact figure.
Two limits should be considered separately. One is the count shown for the search. The other is the number of items a filtered query can return through pagination. GitHub's REST API documentation says workflow run searches using parameters such as actor, branch, created, event, head_sha, or status return at most 1,000 results per search. Each page can contain up to 100 items through the per_page parameter.
Which automations should be reviewed
Not every integration needs a change. The main risk is in routines that use the count as control logic or expect to sweep more than 1,000 results in one search. Review automations that do one or more of the following:
- compare the returned count with an expected number to decide whether collection is complete;
- use the count as the denominator for metrics, percentages, or coverage indicators;
- assume a broad search represents all historical runs in a repository;
- stop pagination because the reported total appears to have been reached;
- build compliance or audit reports that depend on an exact total of workflow runs;
- query long periods using only broad filters such as branch, actor, event, or status.
If an automation only retrieves recent runs, looks up a specific run, works with a short time range, or processes a small number of pages, the change may have no practical effect. Regression tests are still useful to confirm that no code performs rigid conversions or comparisons against the reported count.
What should not be assumed about the API
The announcement states that GitHub will report “2,500+” when the number of matches exceeds 2,500, but the changelog does not describe a type change for a specific REST response field. An integration therefore should not assume, without testing the endpoint it uses, that a numeric field such as total_count simply became a string.
The safe implementation point is to treat the count from large queries as non-exact and avoid critical logic that depends on learning the real total from a single broad search. When code depends on the exact response format, validate the endpoint and API version used by the integration before changing parsing, typing, or schemas.
How to split large queries
GitHub's recommended approach is to narrow filters. For large histories, a practical strategy is to split searches into time windows with the created parameter. Instead of requesting all runs for a branch or actor over an open-ended period, an automation can query month by month, week by week, or with another interval appropriate to the volume.
The ideal window size depends on workflow frequency. A repository with hundreds of runs per day likely needs smaller slices than a project with only a few runs per week. The operational rule is to choose filters that keep each search below the relevant limits and reduce the window again when needed.
In addition to dates, the API supports combining filters such as actor, branch, event, and status. This helps turn a very broad request into smaller, verifiable sets. The application can then aggregate results locally and deduplicate by workflow run identifier if windows or criteria overlap.
Pagination still matters
The count change does not remove pagination rules. GitHub's documentation states that per_page accepts at most 100 items. For filtered searches, the workflow runs listing endpoint caps each search at 1,000 results. Increasing page size therefore does not solve the need to partition a query that matches thousands of runs.
A robust routine should paginate while valid pages remain within the current search and separately control movement to the next filter window. This design reduces dependence on a global count and makes it clearer which intervals have already been processed.
Checklist for scripts and integrations
- Find broad queries. Look for workflow run listing calls filtered by workflow, event, status, branch, actor, or long periods.
- Identify count dependencies. Check conditions, loops, dashboards, and metrics that assume the reported count is exact.
- Separate counting from collection. Do not use one global number as the only proof that every record has been processed.
- Partition history. Add date ranges or other filters to keep searches smaller.
- Paginate within each search. Respect per_page and pagination, remembering that a filtered search can return at most 1,000 results.
- Test real responses. Confirm the behavior of the endpoint and API version used by your integration, especially when type or schema validation is involved.
- Protect historical reporting. If a metric requires an exact total, calculate it from complete partitioned sets rather than the count from one broad query.
Who is affected and where the change is rolling out
GitHub says the change is rolling out on github.com and GitHub Enterprise Cloud. The announcement does not state that the same behavior is already present in every GitHub Enterprise Server version. Teams running different environments should validate behavior on the platform they actually use before standardizing one parsing strategy across all deployments.
Practical impact on workflows and observability
The change does not alter workflow execution, YAML triggers, or the outcome of jobs that already ran. It affects how large sets of workflow runs are queried and how the size of those sets should be interpreted. The impact is therefore concentrated in tooling around Actions: history collectors, inventories, dashboards, audits, scheduled jobs, and integrations that correlate runs by branch, user, event, or status.
For those tools, the safest adaptation is to stop expecting an exact global count from very large searches. Smaller filters, controlled pagination, and local aggregation reduce the risk of missing runs or producing misleading metrics when volume exceeds the announced limits.
