GitHub cambió la forma en que las consultas de ejecuciones de GitHub Actions informan la cantidad de resultados en la API y en la interfaz. Según el anuncio del 25 de septiembre de 2026, las búsquedas filtradas por workflow, evento, estado, branch o actor dejan de intentar ofrecer un conteo exacto cuando coinciden más de 2.500 registros. En esos casos, GitHub informa la cantidad como “2.500+”. La paginación de resultados continúa disponible y las búsquedas filtradas siguen devolviendo como máximo 1.000 ejecuciones por consulta.
Para los equipos que mantienen scripts, integraciones, dashboards o rutinas de auditoría, el principal punto de revisión es directo: un conteo por encima de ese umbral ya no debe tratarse como el total exacto del conjunto consultado. Si una automatización necesita localizar, exportar o procesar una cantidad muy grande de ejecuciones, GitHub recomienda reducir los filtros, incluso añadiendo rangos de fechas, y realizar consultas más pequeñas.
Qué cambió en las consultas de GitHub Actions
El cambio afecta las consultas de workflow runs tanto en la interfaz como en la API de GitHub Actions. GitHub explica que el comportamiento anterior podía producir un número que parecía preciso pero era incorrecto en búsquedas muy grandes. Las consultas con más de 2.500 registros podían alcanzar un timeout durante el conteo y terminar informando la cantidad encontrada antes de la interrupción, no el total real.
Para reducir ese problema, GitHub decidió sustituir la precisión numérica por una indicación explícita del umbral. Por encima de 2.500 coincidencias, la información significa únicamente que existen más de 2.500 registros. Así se evita que los consumidores interpreten como exacto un conteo parcial de una búsqueda extensa.
Conviene separar dos límites. El primero es el conteo mostrado para la búsqueda. El segundo es la cantidad de elementos que una consulta filtrada puede devolver mediante paginación. La documentación de la API REST de GitHub indica que las búsquedas de workflow runs con parámetros como actor, branch, created, event, head_sha o status devuelven como máximo 1.000 resultados por búsqueda. Cada página puede incluir hasta 100 elementos mediante el parámetro per_page.
Qué automatizaciones conviene revisar
No todas las integraciones necesitan cambios. El riesgo principal está en las rutinas que usan el conteo como lógica de control o esperan recorrer más de 1.000 resultados en una sola búsqueda. Conviene revisar automatizaciones que hagan una o más de estas cosas:
- comparar el conteo devuelto con un número esperado para decidir si la recopilación terminó;
- usar el conteo como denominador de métricas, porcentajes o indicadores de cobertura;
- suponer que una búsqueda amplia representa todas las ejecuciones históricas del repositorio;
- detener la paginación porque parece haberse alcanzado el total informado;
- generar informes de cumplimiento o auditoría que dependan de un total exacto de workflow runs;
- consultar períodos largos usando solamente filtros amplios como branch, actor, evento o estado.
Si la automatización solo recupera ejecuciones recientes, busca un run específico, trabaja con un intervalo corto o procesa pocas páginas, el cambio puede no tener efecto práctico. Aun así, las pruebas de regresión ayudan a confirmar que ningún código convierte o compara el conteo de manera rígida.
Qué no se debe asumir sobre la API
El anuncio informa que GitHub reportará “2.500+” cuando el número de coincidencias supere 2.500, pero el changelog no describe un cambio de tipo para un campo específico de la respuesta REST. Por eso, una integración no debe asumir, sin probar el endpoint utilizado, que un campo numérico como total_count simplemente pasó a ser una cadena de texto.
El criterio seguro para implementar es tratar el conteo de consultas grandes como no exacto y evitar lógica crítica que dependa de obtener el total real a partir de una sola búsqueda amplia. Cuando el código depende del formato exacto de la respuesta, se debe validar el endpoint y la versión de API utilizados por la integración antes de cambiar parsing, tipado o esquemas.
Cómo dividir consultas grandes
La recomendación de GitHub es reducir los filtros. Para historiales extensos, una estrategia práctica consiste en dividir las búsquedas en ventanas de tiempo mediante el parámetro created. En lugar de pedir todas las ejecuciones de una branch o de un actor durante un período indefinido, la automatización puede consultar mes a mes, semana a semana o con otro intervalo adecuado al volumen.
El tamaño ideal de la ventana depende de la frecuencia de los workflows. Un repositorio con cientos de ejecuciones diarias probablemente necesita segmentos más pequeños que un proyecto con pocos runs por semana. La regla operativa es elegir filtros que mantengan cada búsqueda por debajo de los límites relevantes y reducir nuevamente la ventana cuando sea necesario.
Además de la fecha, la API permite combinar filtros como actor, branch, event y status. Esto ayuda a convertir una consulta muy amplia en conjuntos menores y verificables. Luego, la aplicación puede agregar los resultados localmente y eliminar duplicados mediante el identificador de la ejecución si existe superposición entre ventanas o criterios.
La paginación sigue requiriendo atención
El cambio en el conteo no elimina las reglas de paginación. La documentación de GitHub indica que per_page acepta como máximo 100 elementos. En búsquedas filtradas, el endpoint de listado de workflow runs limita cada búsqueda a 1.000 resultados. Por lo tanto, aumentar el tamaño de página no resuelve la necesidad de particionar una consulta que coincide con miles de ejecuciones.
Una rutina robusta debe paginar mientras existan páginas válidas dentro de la búsqueda actual y controlar por separado el paso a la siguiente ventana de filtros. Este diseño reduce la dependencia de un conteo global y deja más claro qué intervalos ya fueron procesados.
Checklist para revisar scripts e integraciones
- Localiza consultas amplias. Busca llamadas de listado de workflow runs filtradas por workflow, evento, estado, branch, actor o períodos largos.
- Identifica dependencias del conteo. Revisa condiciones, bucles, dashboards y métricas que supongan que el conteo informado es exacto.
- Separa conteo y recopilación. No uses un único número global como única prueba de que todos los registros fueron procesados.
- Particiona el historial. Añade rangos de fechas u otros filtros para mantener las búsquedas más pequeñas.
- Pagina dentro de cada búsqueda. Respeta per_page y la paginación, recordando que una búsqueda filtrada puede devolver como máximo 1.000 resultados.
- Prueba respuestas reales. Confirma el comportamiento del endpoint y de la versión de API usados por tu integración, especialmente si existe validación de tipos o esquemas.
- Protege los informes históricos. Si una métrica necesita un total exacto, calcúlalo a partir de conjuntos particionados y completos, no del conteo de una única consulta amplia.
Quién está afectado y dónde se está desplegando el cambio
GitHub informó que el cambio se está desplegando en github.com y GitHub Enterprise Cloud. El anuncio no afirma que el mismo comportamiento ya esté presente en todas las versiones de GitHub Enterprise Server. Los equipos que operan entornos diferentes deben validar el comportamiento en la plataforma realmente utilizada antes de estandarizar una sola estrategia de parsing para todos los despliegues.
Impacto práctico en workflows y observabilidad
El cambio no modifica la ejecución de un workflow, los disparadores YAML ni el resultado de jobs ya ejecutados. Afecta la forma de consultar grandes conjuntos de workflow runs y de interpretar el tamaño de esos conjuntos. El impacto se concentra principalmente en herramientas alrededor de Actions: recolectores de historial, inventarios, paneles, auditorías, jobs programados e integraciones que relacionan ejecuciones por branch, usuario, evento o estado.
Para esas herramientas, la adaptación más segura es dejar de esperar un conteo global exacto en búsquedas muy grandes. Filtros más pequeños, paginación controlada y agregación local reducen el riesgo de perder runs o producir métricas engañosas cuando el volumen supera los límites anunciados.
