Desde 24 de setembro de 2026, artefatos expirados do GitHub Actions deixaram de aparecer no resumo de uma execução e também deixaram de ser retornados pelos endpoints REST destacados pelo GitHub para listar artefatos de um repositório e obter um artefato individual. Antes, o registro podia continuar visível com a indicação de que estava expirado mesmo depois de os arquivos subjacentes já terem sido removidos do armazenamento.
A alteração é de apresentação e consulta, não de política de retenção. O GitHub afirma que ela não muda as configurações de retenção nem a cobrança. Para equipes que usavam a interface ou respostas da API como inventário histórico, porém, há uma consequência prática: a ausência de um artefato expirado passa a ser o comportamento esperado nesses pontos de consulta.
O que mudou na interface do GitHub Actions
No resumo de uma execução de workflow, a lista de artefatos deixa de mostrar itens cujo período de retenção já terminou. O comportamento anterior mantinha o nome do artefato acompanhado de uma indicação de expiração, apesar de os arquivos já terem sido apagados do armazenamento.
Isso reduz uma ambiguidade visual importante. Ver um item marcado como expirado podia sugerir que ainda existia algum objeto armazenado ou que o artefato continuava gerando consumo. Segundo o anúncio do GitHub, a mudança foi feita justamente para evitar essa interpretação.
O que muda na REST API
O GitHub cita dois endpoints afetados diretamente pela mudança: List artifacts for a repository e Get an artifact. Artefatos expirados deixam de ser retornados por essas consultas.
Na prática, integrações que tratavam a presença de registros expirados como parte de um inventário histórico precisam ser revistas. Uma rotina que enumerava artefatos e depois filtrava itens com estado expirado pode deixar de encontrar esses registros, porque a filtragem agora acontece antes de a resposta chegar ao consumidor.
O que não convém inferir
A mudança anunciada não deve ser interpretada como alteração geral em todos os dados de workflow ou como exclusão adicional causada pela API. O ponto confirmado é que artefatos já expirados, cujos arquivos já não existiam no armazenamento, deixam de ser exibidos ou retornados nos locais citados pelo GitHub.
Como revisar automações que consultam artefatos
O principal risco está em scripts, dashboards e integrações que assumem que um artefato expirado ainda aparecerá como registro consultável. Vale revisar especialmente fluxos que:
- contam artefatos expirados para gerar métricas históricas;
- usam a listagem da API para reconstruir tudo o que uma execução já produziu;
- disparam limpeza com base em registros marcados como expirados;
- comparam o total retornado pela API com inventários antigos e tratam diferenças como falha;
- dependem da presença de um artefato expirado para distinguir “nunca existiu” de “existiu e expirou”.
Para esses casos, o comportamento precisa ser ajustado para não considerar ausência na interface ou nos endpoints citados como prova de que o artefato nunca foi criado.
Onde encontrar o histórico depois da expiração
O GitHub informa que, se for necessário saber quais artefatos uma execução produziu depois de eles expirarem, essa informação ainda pode ser encontrada nos logs da execução. Isso transforma os logs em uma referência mais importante para auditoria retrospectiva quando o objetivo é confirmar que determinado artefato foi gerado.
Há uma distinção operacional relevante: logs podem registrar a produção do artefato, mas não restauram o arquivo expirado. A documentação do GitHub trata a expiração como remoção automática do artefato conforme a política de retenção aplicável.
Retenção continua sendo configurada separadamente
Por padrão, o GitHub documenta retenção de 90 dias para artefatos e logs gerados por workflows, salvo configuração diferente aplicável ao repositório, à organização ou à empresa. Também é possível definir um período personalizado para um artefato individual por meio de retention-days em actions/upload-artifact, respeitando os limites superiores definidos pela política da conta.
Portanto, a mudança de 24 de setembro não é uma redução automática do período de retenção. Ela altera o que é mostrado depois que a expiração já ocorreu.
A mudança não altera a cobrança de armazenamento
O anúncio do GitHub afirma explicitamente que a alteração não modifica cobrança. A documentação de billing explica que o armazenamento do Actions é contabilizado ao longo do tempo e que excluir artefatos reduz o armazenamento atual e interrompe cobranças futuras associadas àquele armazenamento, sem apagar uso já acumulado no ciclo de cobrança.
Isso ajuda a interpretar corretamente a nova interface: deixar de ver um artefato expirado não é um novo mecanismo de economia introduzido por esta mudança. O efeito financeiro continua ligado ao armazenamento efetivamente mantido e às regras de cobrança, não à visibilidade do registro na tela.
Checklist de revisão para equipes
- Verifique se algum script espera receber artefatos expirados nos endpoints citados pelo GitHub.
- Revise métricas que usam quantidade de artefatos retornados como série histórica.
- Evite classificar um artefato como “nunca criado” apenas porque ele não aparece mais após a expiração.
- Use logs da execução quando precisar comprovar retrospectivamente quais artefatos foram produzidos.
- Confirme a política de retenção configurada no repositório, organização ou empresa quando o problema for duração do armazenamento, e não visibilidade.
- Separe diagnóstico de cobrança de diagnóstico de listagem: a nova ocultação não muda a política de billing.
O que muda para a revisão de segurança e confiabilidade
Para times de desenvolvimento e segurança, a principal implicação é de observabilidade. Ferramentas internas que usavam a API como fonte histórica podem passar a ter lacunas esperadas depois da expiração. Isso exige distinguir três estados que antes podiam ser inferidos pela própria listagem: artefato disponível, artefato expirado e artefato sem registro visível.
Depois da mudança, a diferenciação entre “expirou” e “não existiu” pode depender de outra evidência, especialmente dos logs da execução ou de dados que a própria organização tenha persistido antes da expiração. Se esse histórico for importante para auditoria, investigação de incidentes ou rastreabilidade de builds, a revisão deve ocorrer antes que a retenção elimine o artefato da listagem.
