GitHub has changed how large GitHub Actions workflow-run searches report their counts. When a query filtered by workflow, event, status, branch, or actor finds more than 2,500 runs, the GitHub Actions UI and API now report `2,500+` instead of attempting to return a misleading exact total. GitHub says this change improves accuracy and performance. Read the changelog announcement and the workflow runs API reference for the endpoint details.
The practical consequence is simple: `total_count` is no longer a precise metric for a broad query above that threshold. If your dashboard displays an exact number, your cleanup job assumes a count is complete, or your script decides whether to page based on that number, update it now.
What changed in the Actions API
GitHub continues to return paginated workflow runs, with up to 1,000 items available through the query. The count is the part that changed. For more than 2,500 matching runs, GitHub reports `2,500+` rather than pretending that a timeout-prone count is exact.
This is not a deletion of workflow history. It is not a new retention limit. It is a change to the count returned by filtered queries in the UI and API on GitHub.com and GitHub Enterprise Cloud.
Why exact counts became unreliable
A broad workflow-run query can match a very large dataset. Attempting to count every match may time out, then return a number based on the records found before the timeout. That number looks exact even though it is incomplete. A bounded `2,500+` result is more honest and lets GitHub keep the list and UI responsive.
Do not use total_count as your pagination guard
A fragile client often looks like this: request page one, read `total_count`, calculate the number of pages, and stop. That breaks when the count is `2,500+`, and it was already risky when the count could be incomplete. Use the API’s pagination links or fetch pages until the response has no next page. If your use case only needs recent data, narrow the query first.
# Narrow a workflow-run query by workflow, status, branch, and date
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/repos/OWNER/REPO/actions/runs?workflow_id=build.yml&status=completed&branch=main&created=2026-09-01..2026-09-29&per_page=100"The available filters depend on the endpoint and your reporting goal. Useful dimensions include workflow, event, status, branch, actor, and a date range. A date range is often the most effective first filter because it makes the query bounded and gives the report a clear time window.
Build reports around windows, not one giant total
For monthly reporting, query one day or week at a time and sum the records you actually retrieve. Keep the time zone and boundary convention fixed. Store the query parameters with the result so another person can reproduce the report.
For failure monitoring, query a recent window and filter to `status=completed`. Count conclusions locally from the returned runs. For retention or cleanup, use a bounded age window rather than asking the API for every run ever created.
Update dashboards and scripts safely
1. Search for code that reads `total_count` from Actions workflow-run responses.
2. Treat a value such as `2,500+` as a lower bound or display label, never as an integer.
3. Replace count-based page calculations with pagination-link handling.
4. Add date ranges or other filters to reports that do not need all history.
5. Record the number of runs retrieved locally and label it as a filtered-window count.
6. Test empty results, one page, exactly 2,500 matches, and more than 2,500 matches.
If your UI must show a single number for an unbounded query, display `2,500+` or `more than 2,500` and link to the filters behind it. Do not convert the value to 2,500 and call it exact. That hides the uncertainty the API is now deliberately exposing.
A practical query strategy
For an organization-wide reliability report, start with each repository and a seven-day window. Split further by workflow or branch when a repository still exceeds the threshold. For a single workflow, use its workflow ID or file name and query by week. For incident response, filter by actor, event, branch, and the incident time range, then widen the window only when the evidence requires it.
This approach has two benefits: the data is easier to explain, and retries are cheaper when a request fails. A bounded report also makes it easier to compare weeks without mixing old workflow behavior with current behavior.
The short version
`2,500+` is a signal to narrow the query, not a number to parse. Use filters, date windows, and pagination links. Count the records you actually retrieve, keep the query parameters beside the report, and let your UI show when the result is a lower bound.