Seu GitHub Actions parou de funcionar? Descubra como resolver o problema

Se uma automação não iniciou, ficou presa na fila ou terminou com erro, este roteiro ajuda a descobrir em que etapa o problema está. Ele serve para quem mantém um projeto com GitHub Actions e precisa separar uma falha do serviço de um erro na configuração ou no código.

Em 19 de outubro de 2026, o GitHub registrou uma interrupção que afetou o processamento de workflows, implantações do GitHub Pages e entrega de webhooks. O incidente foi resolvido no mesmo dia. Se seu workflow falhou naquele período, a ocorrência pode explicar atrasos; para uma falha nova, confira o status atual e siga os passos abaixo.

Antes de mudar o arquivo YAML ou repetir a execução, descubra se o workflow nem começou, está aguardando um runner ou falhou em um passo específico.

Abra a página de status do GitHub e procure Actions. Se o aviso também mencionar GitHub Pages ou Webhooks, verifique se o seu problema depende desses serviços. Durante um incidente, pode haver atraso na fila ou na atualização da tela mesmo depois de o job ter iniciado.

O incidente de 19 de outubro foi marcado como resolvido às 16h56 UTC, às 13h56 no horário de Brasília. Isso descreve aquele evento, não garante que o serviço esteja operacional em outra data. Use o status atual quando for investigar seu próprio erro.

• Se Actions estiver com incidente aberto, aguarde a atualização do GitHub e evite disparar dezenas de novas tentativas.
• Se todos os serviços estiverem operacionais, continue para o histórico do workflow.
• Se o job foi afetado durante o incidente e já voltou ao normal, reexecute apenas a execução necessária.

No repositório, abra a aba Actions e escolha o workflow na coluna da esquerda. Veja se existe uma execução correspondente ao commit ou à pull request que você esperava. A diferença entre não haver execução e haver uma execução com falha aponta para causas diferentes.

Se nenhuma execução apareceu, abra o arquivo em .github/workflows e confira o campo on. Veja se o evento usado no arquivo corresponde à ação que você fez, como push ou pull_request, e se filtros de branch ou caminho permitem aquele commit. Confirme também que o workflow não foi desativado e que o evento pode ser executado na branch em que você está trabalhando.

Workflows agendados têm uma regra especial: o arquivo precisa estar na branch padrão. Em repositórios com filtro de caminhos, confira se o arquivo alterado realmente corresponde ao padrão. Uma condição no próprio job também pode fazer uma execução ser criada, mas deixar o job marcado como ignorado.

Se o run aparece como queued, abra a execução e veja se há um motivo exibido junto do job. Um runner hospedado pode estar aguardando capacidade. Um runner próprio pode estar desligado, ocupado ou sem as etiquetas pedidas pelo arquivo. Em um repositório de organização, uma regra de aprovação ou grupo de runners também pode deixar o job aguardando.

Para um runner próprio, abra Settings, Actions e Runners e confira se ele aparece online e ocioso. Compare as etiquetas configuradas no runner com o valor de runs-on no workflow. Se o job usa um ambiente protegido, verifique se há uma aprovação pendente antes de alterar a configuração.

Uma fila curta não significa necessariamente defeito. Se a demora continuar, confira a página de status e a configuração do runner antes de cancelar e criar várias cópias do mesmo trabalho.

Se o workflow não inicia com push ou pull request, mas você tem permissão para executá-lo manualmente, o evento workflow_dispatch pode ajudar a testar a configuração. O arquivo precisa estar na branch padrão para que o botão Run workflow fique disponível. A execução manual não prova que todos os gatilhos automáticos estão corretos, mas ajuda a separar um problema de evento de um erro no job.

on:
  workflow_dispatch:
  push:
    branches: [main]
  pull_request:
    branches: [main]

Nesse exemplo, o workflow pode iniciar manualmente e também quando há push ou pull request direcionado à branch main. Se o projeto usa outra branch padrão, troque main pelo nome correto. Para testar, abra Actions, selecione o workflow e escolha Run workflow. Se essa opção não aparecer, confirme primeiro que o arquivo já está na branch padrão.

Depois da execução manual, verifique o mesmo fluxo de logs usado em uma execução automática. Se o job funciona manualmente, mas não começa quando você envia código, volte aos filtros do evento, às condições e aos caminhos configurados. Não mantenha um gatilho manual aberto se o projeto não precisa dele.

Quando o status estiver failed, abra a execução, selecione o job e expanda o primeiro passo em vermelho. Leia algumas linhas antes da mensagem final: a última linha costuma repetir o erro, enquanto o contexto anterior mostra qual comando e qual arquivo o produziram.

Por exemplo, se npm ci informa que o arquivo de lock não corresponde ao package.json, sincronize as dependências no seu computador, gere o lock correto e envie os dois arquivos juntos. Se o log disser que uma variável está ausente, confira o nome usado no YAML e cadastre o valor em Settings, Secrets and variables. Não cole segredos diretamente no workflow.

Você também pode consultar falhas recentes pelo GitHub CLI. Troque o número do exemplo pelo identificador da execução exibido na página:

gh run list --limit 10
gh run view ID_DA_EXECUCAO --log-failed

Compare o erro com a mudança que disparou a automação. Assim você evita alterar permissões, versões de ferramentas ou configurações que não têm relação com a primeira falha.

Se a falha veio de um erro real no projeto, ajuste o código ou a configuração e envie uma nova alteração. Se o GitHub confirmou um incidente e já o resolveu, reexecute o job que foi afetado. Na página da execução, use Re-run jobs e escolha todos os jobs ou somente os que falharam.

Pelo terminal, é possível repetir apenas os jobs com falha:

gh run rerun ID_DA_EXECUCAO --failed

A nova tentativa usa o mesmo commit e a mesma referência da execução original. Se a causa estiver no código, repetir sem corrigir vai produzir o mesmo resultado. A opção de depuração pode ser útil quando o log não mostra detalhes suficientes; ative-a só quando realmente precisar investigar mais.

Use uma nova execução para confirmar a correção, não para esconder a primeira falha.

Confira se o repositório tem as permissões de Actions esperadas, se os limites de cobrança ou armazenamento foram atingidos e se algum ambiente exige aprovação. Se os logs não indicarem a causa, ative o registro de depuração temporariamente e abra uma execução controlada. Depois remova informações extras que possam expor dados sensíveis antes de compartilhar os logs.

Ao pedir ajuda, informe o link da execução, o nome do job, o primeiro passo que falhou e um trecho do erro sem tokens, senhas ou dados de clientes. Com esses dados, outra pessoa consegue localizar o problema sem receber acesso ao projeto inteiro.

Se a tela indicar que o workflow foi ignorado, procure as condições if, os filtros de branch e os filtros de caminhos antes de investigar o runner. Se aparecer uma mensagem de permissão, confira as permissões declaradas pelo workflow e pelo token usado naquela etapa. Se o problema ocorrer apenas em um runner próprio, verifique o serviço do runner e a conectividade da máquina que o hospeda.

Quando a execução terminar por limite de minutos ou armazenamento, consulte a área de cobrança do repositório ou da organização. Essa causa é diferente de uma falha de código, e aumentar tentativas não libera capacidade. Um administrador precisa revisar o uso e as regras do plano antes de alterar a configuração.

Para reduzir diagnósticos repetidos, registre o nome do workflow, a branch, o evento e o resultado esperado em uma nota curta para a equipe. Um histórico simples ajuda a perceber se a mesma falha volta depois de uma atualização de dependência, mudança de segredo ou alteração de runner.