Resposta rápida
Se um workflow com runs-on: self-hosted ficou na fila ou o runner deixou de registrar depois de 25 de setembro de 2026, confirme primeiro a versão do aplicativo do runner. Nessa data, o GitHub Enterprise Cloud iniciou a fiscalização plena de versões mínimas: runners antigos podem deixar de registrar, receber ou executar jobs mesmo que funcionassem antes.
Não reinstale imediatamente. Verifique no GitHub se o runner está online, ocioso e com os labels exigidos; consulte a versão pela API; cheque o serviço e os logs _diag na máquina; e só então compare a versão com o endpoint oficial de depreciação. Fila parada também pode ser causada por label incorreto, serviço desligado, rede, falta de capacidade ou incidente do GitHub Actions.
O que passou a valer em 25 de setembro
O GitHub anunciou que qualquer atualização do aplicativo do runner, inclusive patch, inicia uma janela de atualização. Se o software ficar 30 dias sem acompanhar uma versão disponível, o serviço pode deixar de enviar jobs; uma correção crítica de segurança pode bloquear a fila imediatamente até a atualização.
A fiscalização plena para GitHub Enterprise Cloud começou em 25 de setembro de 2026. Depois do prazo, runners abaixo do mínimo de registro não conseguem registrar ou registrar novamente, enquanto runners abaixo do mínimo de execução deixam de processar jobs existentes. A mudança se aplica ao github.com; o GitHub Enterprise Server segue os requisitos da versão instalada e não entrou nesse cronograma.
Como saber se a versão é realmente a causa
Abra Settings > Actions > Runners no nível em que o runner foi cadastrado. Anote nome, status, arquitetura, labels e versão. Pela API REST, a listagem de runners devolve status, busy, ephemeral e version. Depois consulte /actions/runners/deprecations/{version} no repositório, organização ou enterprise para obter o fim do suporte de registro e de execução daquela versão.
Não use apenas a versão mais recente mostrada na página pública de releases. O projeto adota distribuição progressiva e orienta confirmar a versão esperada nas instruções de download da sua organização ou do repositório. Em 28 de setembro, a página pública apresentava a 2.337.0, mas o valor autorizado para o seu ambiente deve vir do painel ou da API oficial.
- Confirme se o job exige runs-on: self-hosted e quais labels adicionais ele pede.
- Abra a lista de runners e compare status, busy, labels, sistema e versão.
- Consulte o endpoint de depreciação usando exatamente a versão encontrada.
- Verifique se outros jobs chegam ao mesmo runner ou ao mesmo grupo.
- Consulte o GitHub Status antes de atribuir a falha ao host.
Fila aguardando runner não é sempre versão antiga
Quando nenhum runner online combina com todos os labels do job, a execução pode permanecer na fila por até 24 horas. Um runner com label linux não atende automaticamente um job que também exige gpu ou um label personalizado. Mudanças em grupos, permissões de acesso e escopo entre repositório, organização e enterprise também podem deixar o job sem destino compatível.
Se o runner aparece online e busy, pode haver apenas falta de capacidade. Se aparece offline, investigue serviço, rede, proxy, certificado e resolução DNS. Se ele nem aparece mais, considere expiração por inatividade ou falha no registro. Atualizar a versão não corrige um label removido, um serviço parado ou um host sem saída HTTPS.
Verifique o serviço e os logs antes de atualizar
Em Linux, execute sudo ./svc.sh status no diretório do runner quando ele foi instalado como serviço. No Windows, consulte Get-Service "actions.runner.*"; no macOS, use ./svc.sh status. Esses comandos confirmam se o processo está ativo, mas não provam que a conexão com o GitHub foi estabelecida.
A documentação recomenda revisar os arquivos Runner_ e SelfUpdate dentro de _diag. Procure a versão iniciada, tentativa de atualização, erro de autenticação, proxy, DNS ou TLS e o momento em que a conexão caiu. Preserve esses registros antes de remover ou registrar novamente o runner, pois uma reinstalação pode apagar a melhor evidência da causa.
- Pause novos deploys que dependem exclusivamente do runner afetado.
- Confira o estado do serviço no sistema operacional.
- Copie os logs Runner_ e SelfUpdate de _diag para um local protegido.
- Compare o horário da falha com a mudança de versão e com o GitHub Status.
- Corrija serviço ou conectividade antes de substituir a instalação.
Como atualizar um runner persistente
Por padrão, o self-hosted runner se atualiza automaticamente. Se a atualização travou, pare de enviar novos jobs, aguarde o job atual terminar e revise os logs do SelfUpdate. Reinicie o serviço somente depois de confirmar que nenhum deploy está sendo executado. Use as instruções de download exibidas pelo próprio GitHub para o repositório ou organização, pois elas refletem sistema, arquitetura e versão esperada.
Se o runner foi registrado com --disableupdate, a manutenção é responsabilidade da equipe. Baixe o pacote oficial correspondente, valide a origem e siga as instruções do release. Preserve a pasta _work se ela contém estado necessário, mas não reutilize binários antigos por cima de uma instalação ativa sem o procedimento do ambiente. Após a atualização, inicie o serviço, confirme a nova versão e execute um workflow de teste sem segredos de produção.
Contêineres e runners efêmeros exigem outra correção
Em runners efêmeros, atualizar um contêiner em execução não resolve a origem do problema. Troque a versão no Dockerfile, imagem-base, template de VM ou configuração do Actions Runner Controller, publique uma imagem nova e recrie os pods ou máquinas. Caso contrário, cada escala volta a criar runners antigos.
Revise também caches de imagem, tags mutáveis e automações que fixam uma versão anterior. O comunicado do GitHub recomenda atualizar scripts de instalação, imagens e templates e recriar runners derivados de artefatos antigos. Faça uma implantação gradual e mantenha capacidade suficiente para que a fila não migre inteira para um único host.
Como validar que a correção funcionou
Depois de iniciar o runner, confirme que ele aparece online, com a versão e os labels esperados. Execute um workflow pequeno que use os mesmos labels, registre o tempo até o job começar e confira se os logs mostram a sessão conectada. Em seguida, retome um pipeline real controlado e valide checkout, cache, artefatos e acesso aos serviços internos.
Não conclua que tudo voltou apenas porque o runner ficou verde. Um job pode iniciar e falhar depois por runtime, permissões ou dependências do host. Se o pipeline também começou a falhar após a remoção do Node 20 das actions JavaScript, trate essa migração separadamente; atualizar o aplicativo do runner e atualizar uma action são mudanças diferentes.
- Confirme online, versão, grupo e labels no GitHub.
- Rode um job de diagnóstico sem credenciais sensíveis.
- Verifique tempo de fila, início e conclusão do job.
- Teste um pipeline real de baixo risco e compare os artefatos.
- Monitore novas tentativas de autoatualização nos logs _diag.
Limitações e cuidados
O GitHub publica os critérios e as datas, mas a versão mínima efetiva pode variar ao longo do rollout. Não copie um número deste artigo para todos os ambientes. Consulte a versão esperada no painel e o endpoint de depreciação antes de bloquear uma imagem ou automatizar alertas.
A API exige permissão de leitura de self-hosted runners no escopo consultado. Não exponha tokens, URLs de registro nem conteúdo dos logs em tickets públicos. A página de status mostra a saúde agregada do serviço e não substitui a inspeção do runner, da rede e dos labels.
Próxima ação útil
Este guia foi verificado em 28 de setembro de 2026. Exporte hoje a lista de runners com nome, status, versão, sistema, arquitetura e labels. Consulte o prazo de cada versão pela API, priorize os que sustentam deploy e segurança e corrija também as imagens ou templates que recriam versões antigas.
Depois, crie um alerta para runner offline, aumento do tempo de fila e versão próxima da depreciação. Uma atualização emergencial recupera o pipeline; um inventário contínuo evita que o mesmo bloqueio reapareça no próximo release.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Minimum version enforcement timeline for self-hosted runnersGitHub Changelog
- Self-hosted runners referenceGitHub Docs
- REST API endpoints for self-hosted runnersGitHub Docs
- Monitor and troubleshoot self-hosted runnersGitHub Docs
- Configure the self-hosted runner application as a serviceGitHub Docs
- actions/runner releasesGitHub
- GitHub StatusGitHub