Rongchai Wang
17 ene 2026 09:16
GitHub introduce limitación de tasa para entradas de caché de Actions a 200 cargas por minuto por repositorio, abordando preocupaciones de estabilidad del sistema debido a cargas de alto volumen.
GitHub ha implementado un nuevo límite de tasa en su sistema de caché de Actions, limitando las cargas a 200 nuevas entradas de caché por minuto para cada repositorio. El cambio, anunciado el 16 de enero de 2026, se dirige a repositorios que estaban sobrecargando el sistema de caché con cargas rápidas y causando problemas de estabilidad en toda la plataforma.
Las descargas permanecen sin afectar. Si tus flujos de trabajo extraen entradas de caché existentes, nada cambia. El límite se dirige específicamente a la creación de nuevas entradas, una distinción que importa para equipos que ejecutan compilaciones paralelas que generan datos de caché nuevos.
¿Por qué ahora? GitHub citó el "cache thrash" como el culpable. Los repositorios que cargaban volúmenes masivos de entradas de caché en ráfagas cortas estaban degradando el rendimiento para todos los demás en la infraestructura compartida. El límite de 200 por minuto ofrece a los usuarios intensivos suficiente margen para casos de uso legítimos mientras previene el tipo de abuso que estaba desestabilizando el sistema.
Parte de una Revisión Más Amplia de Actions
Este límite de tasa llega en medio de varios cambios significativos en la economía de GitHub Actions. A principios de este mes, GitHub redujo los precios en runners alojados entre un 15% y 39% según el tamaño. Pero la noticia más grande llega el 1 de marzo de 2026, cuando el uso de runners autoalojados en repositorios privados comenzará a costar $0.002 por minuto, un nuevo cargo que está empujando a algunos equipos a reconsiderar completamente su arquitectura de CI/CD.
El sistema de caché en sí mismo obtuvo una actualización a finales de 2025, con repositorios ahora capaces de exceder el límite anterior de 10 GB mediante precios de pago por uso. Cada repositorio aún obtiene 10 GB gratis, pero los usuarios intensivos ahora pueden comprar más en lugar de luchar constantemente contra las políticas de desalojo.
Qué Deben Verificar los Equipos
La mayoría de los flujos de trabajo no notarán este límite. Pero si estás ejecutando compilaciones matriciales que generan claves de caché únicas en docenas de trabajos paralelos, haz las cuentas. Una matriz de 50 trabajos completándose simultáneamente teóricamente podría alcanzar 200 cargas de caché en menos de un minuto si cada trabajo crea múltiples entradas.
La solución es sencilla: consolida las claves de caché donde sea posible, o escalonar la finalización de trabajos si realmente estás chocando contra el límite. GitHub no ha anunciado ningún panel de monitoreo para tasas de carga de caché, por lo que los equipos preocupados por alcanzar los límites necesitarán auditar sus registros de flujo de trabajo manualmente.
Fuente de imagen: Shutterstock
Fuente: https://blockchain.news/news/github-actions-cache-rate-limit-200-per-minute
