GitHub Actions query count handling has been altered: when you filter workflow runs by workflow, event, status, branch, or actor, the API and UI now return a less precise but more reliable total, capping the displayed number at “2,500+” for large result sets. This matters because scripts and dashboards that depend on exact counts or bulk retrieval of runs may see different numbers and need to adjust their queries to avoid timeouts.
Change Overview
The new behavior limits the reported total to a maximum of 2,500 items. If a query would return more than that, the response shows the string “2,500+” instead of an exact figure. Pagination of individual items continues unchanged, with each page delivering up to 1,000 workflow‑run records.
Operational Impact
Large‑scale queries that previously timed out and returned a premature count will now complete faster, because the service stops counting after the threshold is reached. The trade‑off is a loss of precision for totals above the limit, but the count is guaranteed to be accurate up to that point.
Implementation Guidance
Any automation that expects an exact numeric total above 2,500 should be updated. Practical steps include:
- Adding a date range or other narrowing filter to keep result sets below the threshold.
- Iterating through paginated pages (
per_page=1000) if you need to process every run, rather than relying on the total count. - Validating that downstream logic can handle the literal string “2,500+” without causing parsing errors.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review existing GitHub Actions queries for reliance on exact totals or bulk fetches exceeding 2,500 runs. Refactor those queries to include tighter filters or to process results page‑by‑page. Monitoring for unexpected “2,500+” responses will help identify scripts that need adjustment, ensuring continued reliability and performance of CI/CD pipelines.
