GitHub empieza a aplicar desde este 1 de octubre de 2026 la política de retención de Actions también a checks, workflow runs y statuses. Hasta ahora, una organización podía configurar cuánto conservar artifacts y logs, pero ciertos metadatos permanecían más tiempo. Desde hoy, GitHub eliminará automáticamente esos registros cuando superen el periodo definido, según el aviso oficial de GitHub.
Qué datos empiezan a desaparecer
La política afecta a checks, ejecuciones de workflows y estados asociados. GitHub vincula ahora su ciclo de vida al mismo ajuste de retención que ya utiliza cada repositorio, organización o empresa para Actions. Cuando un registro supere ese límite, dejará de estar disponible en la plataforma.
Artifacts y logs continúan sujetos a la retención ya configurada. La diferencia es que ahora los metadatos relacionados dejan de mantenerse indefinidamente fuera de ese ciclo.
Qué debe hacer una empresa que necesita históricos
GitHub recomienda revisar la configuración de retención y comprobar que cubre el periodo necesario para auditorías, soporte o cumplimiento. Si una organización necesita conservar información más tiempo, debe aumentar el plazo dentro de los máximos permitidos o exportar los datos antes de que sean eliminados.
En repositorios públicos, GitHub mantiene un máximo de 90 días. Las políticas empresariales pueden imponer límites adicionales.
El cambio también puede afectar al coste de almacenamiento
GitHub señala que una retención más corta elimina antes artifacts y logs y puede reducir el almacenamiento facturable de Actions. Checks, workflow runs y statuses no se facturan como almacenamiento, pero los archivos asociados sí.
Eso significa que no conviene ampliar el periodo solo por comodidad sin calcular cuánto histórico necesita realmente el equipo. Una pyme puede separar lo que debe conservar por cumplimiento de lo que solo resulta útil durante la operación diaria.
Qué revisar hoy
Los administradores deberían comprobar el ajuste de retención en repositorios críticos, exportar ejecuciones necesarias para auditorías y validar que herramientas externas no dependan de históricos que vayan a desaparecer. También conviene documentar desde qué fecha comienza a aplicarse la limpieza para no confundir una eliminación por política con una pérdida de datos inesperada.
Este cambio encaja con otras novedades recientes que conviene revisar en equipos técnicos: la actualización de GitHub CodeQL, el proof of presence de GitHub, la adopción de passkeys en Microsoft Entra, el parche crítico de GitLab, el nuevo Microsoft Defender ISOC y Cloudflare Threat Signals.
Fotografía: Christina Morillo / Pexels.
