GitHub меняет отображение количества запусков workflow в API и веб-интерфейсе Actions. Если запрос с фильтром находит более 2500 записей, платформа сообщает «2,500+» вместо точного общего числа. Постраничная выдача при этом сохраняется, но один запрос по-прежнему позволяет получить не более 1000 результатов.
Обновление затрагивает поиск по workflow, событию, статусу, ветке и исполнителю — пользователю или приложению, инициировавшему запуск. Изменение уже развёртывается на github.com и в GitHub Enterprise Cloud, говорится в официальном сообщении GitHub от 25 сентября 2026 года.
Для большинства репозиториев новый порог останется незаметным. Проверить интеграции стоит командам с интенсивным CI/CD, а также разработчикам AI-сервисов, у которых GitHub Actions регулярно запускает тесты моделей, оценочные наборы, сборку контейнеров или развёртывание агентов.
Точное число заменили более надёжной нижней границей
Раньше GitHub пытался подсчитать все совпадения, даже если выборка охватывала несколько тысяч запусков. По объяснению компании, запросы с более чем 2500 найденными записями часто завершались по тайм-ауту. В результате отображалось не фактическое общее число, а количество записей, которое система успела обнаружить до прерывания операции.
Теперь GitHub отказывается от такого псевдоточного значения. Отметка «2,500+» означает только то, что условию соответствуют более 2500 запусков. Она не показывает верхнюю границу и не позволяет определить разницу между, например, 2600 и 20 000 результатами.
Это изменение относится именно к подсчёту и выдаче крупных выборок. Оно не означает, что история запусков после достижения порога удаляется или становится недоступной. Однако получить все записи одним широким запросом нельзя: для полной выгрузки необходимо разделить выборку на более узкие части.
Важно также не путать общий предел выдачи с размером страницы. GitHub продолжает использовать постраничную загрузку, описанную в документации по пагинации REST API, но совокупная выдача одного отфильтрованного запроса ограничивается 1000 элементами.
Где изменение может нарушить автоматизацию
Главный риск связан не с самим отображением «2,500+», а с предположениями, заложенными в код интеграций. Скрипт может считать поле общего количества точным, использовать его для расчёта числа страниц или завершать выгрузку после достижения ожидаемого значения.
Проверка нужна в нескольких сценариях:
- внутренний дашборд показывает число успешных и неудачных запусков за квартал или год;
- система контроля расходов сопоставляет количество workflow-запусков с использованием вычислительных ресурсов;
- аудит собирает полную историю запусков для заданной ветки или пользователя;
- автоматический отчёт рассчитывает процент ошибок на основе общего числа результатов;
- конвейер разработки LLM или AI-агента хранит метрики тестовых прогонов через GitHub Actions;
- интеграция пытается определить количество страниц из общего счётчика.
Если системе достаточно установить факт высокой активности, значение «более 2500» может быть приемлемым. Для расчёта коэффициентов, финансовой сверки или аудита приблизительного счётчика недостаточно: числитель и знаменатель должны быть собраны из одинаково полных выборок.
Описание REST-метода для получения запусков и доступных параметров фильтрации находится в справочнике GitHub Actions API. При этом changelog не уточняет, в каком именно поле и типе данных API передаёт новое обозначение. Поэтому не следует заранее предполагать, что интеграция получит строку `2,500+`, число `2500` или отдельный признак превышения порога. Это нужно проверить на реальном ответе API.
GitHub также не сообщил об аналогичном обновлении для GitHub Enterprise Server. В объявлении названы только github.com и GitHub Enterprise Cloud, поэтому переносить это поведение на локальные серверные установки без проверки конкретной версии нельзя.
Как получать точные данные после обновления
Рекомендация GitHub — сужать запросы, прежде всего по времени. Вместо одной выборки за год можно последовательно запрашивать данные по месяцам, неделям или дням. Подходящий интервал зависит от активности репозитория: у проекта с сотнями запусков в сутки даже месячная выборка может превысить порог.
Надёжная схема выгрузки выглядит так:
Задать начальный временной диапазон, например один месяц.
Получить все доступные страницы результатов.
3. Если ответ указывает на превышение 2500 совпадений или достигается предел выдачи, разделить диапазон пополам.
4. Повторять деление, пока каждый интервал не станет достаточно узким.
5. Объединить записи по уникальному идентификатору запуска, исключив дубликаты на границах диапазонов.
6. Сохранить собственный итоговый счётчик после завершения выгрузки.
При регулярной синхронизации эффективнее не перечитывать всю историю. Интеграция может хранить время или идентификатор последнего обработанного запуска и запрашивать только новые записи. Повторное чтение небольшого перекрывающегося интервала поможет учесть задержавшиеся события, но потребует дедупликации.
Отдельно стоит проверить обработку ошибок и повторных запросов. Разбиение большого периода на десятки небольших окон увеличивает число обращений к API, поэтому интеграция должна учитывать ограничения частоты запросов и не запускать все интервалы одновременно.
Практическая проверка для команды
Сначала найдите обращения к спискам запусков Actions и отчёты, использующие общий счётчик. Особое внимание следует уделить запросам без временного диапазона, а также выборкам по основной ветке за весь срок существования репозитория.
Затем сохраните необработанный ответ API в тестовой среде и проверьте:
- остаётся ли тип поля счётчика прежним;
- как обозначается превышение порога;
- прекращает ли клиент пагинацию на основании общего количества;
- умеет ли код разбивать период на меньшие интервалы;
- исключаются ли дубли после объединения результатов;
- предупреждает ли интерфейс пользователя, если число является нижней границей, а не точным итогом.
Не стоит проверять изменение созданием тысяч фиктивных запусков в рабочем репозитории. Безопаснее использовать уже активный проект или тестовую копию данных и начать с анализа текущего объёма истории.
Из опубликованного GitHub описания нельзя сделать вывод, что лимит сокращает срок хранения запусков, меняет правила биллинга или затрагивает артефакты Actions. Подтверждено только новое поведение крупных отфильтрованных запросов. Командам, которым нужен точный итог, следует считать его самостоятельно после выгрузки данных по ограниченным временным интервалам.
