This article is a technical explanation and implementation example generated using AI. Although the provided code and procedures are structured based on primary sources, the author has not verified the operation on actual hardware. Operation may vary depending on the environment and version. Based on official information, we organize the key points for safely and practically understanding changes to query results in the GitHub Actions API and user interface (UI). To prevent impacts on scripts and integrated systems that handle large-scale workflow execution histories, we examine the background of the specifications and countermeasures.
Overview of changes confirmed from official information
GitHub's official changelog "Changes to query results in the GitHub Actions API and UI" announces specification changes regarding workflow execution search queries.
According to primary sources, when searching by workflow, event, status, branch, actor, etc., the returned record count has been changed to "a more accurate and precision-adjusted count." These changes are being rolled out sequentially on github.com and GitHub Enterprise Cloud.
Search result count limits and the "2,500+" display
The most important point in this change is the specification when the number of found records exceeds 2,500.
The ability to retrieve up to 1,000 items through pagination is maintained.
When the total number of matching records exceeds 2,500, instead of attempting to calculate and return the exact total count, the notation "2,500+" will be reported.
Primary sources explain that queries attempting to retrieve more than 2,500 records frequently caused timeouts, returning the count found up to the timeout point rather than the true total. Establishing this limit aims to increase count precision and improve customer-facing performance.
Workflow query precision and accuracy
In the query behavior before the change, timeouts and the return of partial counts occurred during attempts to forcibly aggregate large amounts of data accurately.
According to the explanation in the primary source, this change provides a "less precise but more accurate count." This is a design change aimed at reducing system-wide resource load while allowing users to stably retrieve reliable information.
Impact on integrated systems and scripts and countermeasures
If existing integrations or automation scripts rely on retrieving more than 2,500 matching workflow runs in a single query, they may be affected by the specification change.
Primary sources recommend an approach for such systems to precisely obtain specific required execution results by "narrowing down filters (e.g., adding a date range)."
flowchart TD
A[ワークフロー実行の検索クエリ実行] --> B{該当レコード数が2,500件を超えるか？}
B -- はい --> C[「2,500+」としてカウントを報告]
B -- いいえ --> D[正確なレコード数を返す]
C --> E[タイムアウトを防ぎパフォーマンスを向上]
D --> E
Precautions and checklist for use
Because this is [before verification on actual hardware], we do not present results obtained directly from screens or via PowerShell regarding actual API responses or UI behavior, but we organize the items that should be verified in advance from an operational perspective.
Check the upper limit of the number of records that scripts retrieve in a single query.
Review whether there are any workflow history search processes that could exceed 2,500 items.
Consider implementing modifications to add filtering criteria, such as date ranges, if necessary.
Summary
The changes covered in this article relate to the aggregation of workflow run query counts in the GitHub Actions API and UI.
When more than 2,500 records are found, "2,500+" is displayed instead of attempting to calculate an exact figure.
The purpose is to prevent timeouts associated with fetching large volumes of data and to improve overall performance and data reliability.
If scripts or integrations rely on extensive run histories, it is necessary to adapt them by adding filtering conditions such as date ranges.
As a pre-execution check, review the code to determine how existing API call logic is affected by the 2,500 threshold and pagination limits.
