Desde el 24 de septiembre de 2026, los artefactos expirados de GitHub Actions ya no aparecen en el resumen de una ejecución y tampoco son devueltos por los endpoints REST destacados por GitHub para listar los artefactos de un repositorio y obtener un artefacto individual. Antes, el registro podía seguir visible con una indicación de expiración aunque los archivos subyacentes ya hubieran sido eliminados del almacenamiento.
El cambio afecta la visualización y la consulta, no la política de retención. GitHub afirma que no modifica la configuración de retención ni la facturación. Sin embargo, para los equipos que utilizaban la interfaz o las respuestas de la API como inventario histórico, hay una consecuencia práctica: la ausencia de un artefacto expirado pasa a ser el comportamiento esperado en esos puntos de consulta.
Qué cambió en la interfaz de GitHub Actions
En el resumen de una ejecución de workflow, la lista de artefactos deja de mostrar los elementos cuyo período de retención ya terminó. El comportamiento anterior mantenía visible el nombre del artefacto con una indicación de expiración aunque los archivos ya hubieran sido eliminados del almacenamiento.
Esto elimina una ambigüedad visual importante. Ver un elemento marcado como expirado podía sugerir que todavía existía algún objeto almacenado o que el artefacto seguía generando uso de almacenamiento. Según el anuncio de GitHub, el cambio se hizo precisamente para eliminar esa incertidumbre.
Qué cambia en la REST API
GitHub menciona dos endpoints afectados directamente: List artifacts for a repository y Get an artifact. Los artefactos expirados dejan de ser devueltos por estas consultas.
En la práctica, deben revisarse las integraciones que trataban los registros expirados como parte de un inventario histórico. Una rutina que enumeraba artefactos y después filtraba los elementos por estado expirado puede dejar de encontrarlos, porque el filtrado ahora ocurre antes de que la respuesta llegue al consumidor.
Qué no conviene inferir
El cambio anunciado no debe interpretarse como una modificación general de todos los datos de workflow ni como una eliminación adicional provocada por la API. El punto confirmado es que los artefactos ya expirados, cuyos archivos ya no existían en el almacenamiento, dejan de mostrarse o devolverse en los lugares citados por GitHub.
Cómo revisar automatizaciones que consultan artefactos
El principal riesgo está en scripts, paneles e integraciones que suponen que un artefacto expirado seguirá apareciendo como registro consultable. Conviene revisar especialmente los flujos que:
- cuentan artefactos expirados para generar métricas históricas;
- usan la lista de la API para reconstruir todo lo que produjo una ejecución;
- activan limpieza basándose en registros marcados como expirados;
- comparan el total devuelto por la API con inventarios antiguos y tratan las diferencias como fallos;
- dependen de la presencia de un artefacto expirado para distinguir “nunca existió” de “existió y expiró”.
En estos casos, la lógica debe ajustarse para que la ausencia en la interfaz o en los endpoints citados no se trate como prueba de que el artefacto nunca fue creado.
Dónde encontrar el historial después de la expiración
GitHub indica que, si es necesario saber qué artefactos produjo una ejecución después de que hayan expirado, esa información todavía puede encontrarse en los logs de la ejecución. Esto convierte a los logs en una referencia más importante para auditorías retrospectivas cuando el objetivo es confirmar que se generó un artefacto determinado.
Existe una distinción operativa importante: los logs pueden registrar que el artefacto fue producido, pero no restauran el archivo expirado. La documentación de GitHub trata la expiración como eliminación automática del artefacto según la política de retención aplicable.
La retención sigue configurándose por separado
De forma predeterminada, GitHub documenta un período de retención de 90 días para artefactos y logs generados por workflows, salvo que se aplique una configuración diferente en el repositorio, la organización o la empresa. También es posible definir un período personalizado para un artefacto individual mediante retention-days en actions/upload-artifact, respetando los límites superiores definidos por la política de la cuenta.
Por lo tanto, el cambio del 24 de septiembre no es una reducción automática del tiempo de retención. Modifica lo que se muestra después de que la expiración ya ocurrió.
El cambio no altera la facturación del almacenamiento
El anuncio de GitHub afirma explícitamente que el cambio no modifica la facturación. La documentación de billing explica que el almacenamiento de Actions se acumula a lo largo del tiempo y que eliminar artefactos reduce el almacenamiento actual y detiene cargos futuros asociados a ese almacenamiento, mientras que el uso ya acumulado en el ciclo de facturación permanece registrado.
Esto ayuda a interpretar correctamente la nueva interfaz: dejar de ver un artefacto expirado no es un nuevo mecanismo de ahorro introducido por este cambio. El efecto financiero sigue vinculado al almacenamiento realmente conservado y a las reglas de facturación, no a la visibilidad del registro en pantalla.
Checklist de revisión para equipos
- Compruebe si algún script espera recibir artefactos expirados desde los endpoints citados por GitHub.
- Revise las métricas que usan la cantidad de artefactos devueltos como serie histórica.
- No clasifique un artefacto como “nunca creado” solo porque deja de aparecer después de la expiración.
- Use los logs de la ejecución cuando necesite demostrar retrospectivamente qué artefactos se produjeron.
- Compruebe la política de retención configurada en el repositorio, la organización o la empresa cuando el problema sea la duración del almacenamiento y no la visibilidad.
- Separe el diagnóstico de facturación del diagnóstico de listado: la nueva ocultación no cambia la política de billing.
Qué cambia para la revisión de seguridad y confiabilidad
Para los equipos de desarrollo y seguridad, la principal implicación es de observabilidad. Las herramientas internas que utilizaban la API como fuente histórica pueden pasar a tener huecos esperados después de la expiración. Esto exige distinguir entre estados que antes podían inferirse más fácilmente desde el propio listado: artefacto disponible, artefacto expirado y artefacto sin registro visible.
Después del cambio, diferenciar “expiró” de “nunca existió” puede depender de otra evidencia, especialmente de los logs de la ejecución o de datos que la propia organización haya conservado antes de la expiración. Si ese historial es importante para auditorías, investigaciones de incidentes o trazabilidad de builds, la revisión debe hacerse antes de que la retención elimine el artefacto del listado.
