Resumo
- Às 23h34 UTC de 19 de julho, o GitHub abriu um incidente crítico no Actions. Novos fluxos podiam atrasar ou não começar, enquanto execuções já iniciadas podiam falhar.
- O impacto chegou a API Requests, Pages e Issues. O GitHub reconheceu efeitos em cadeia provocados pela duração da indisponibilidade e incorporou à mesma investigação a ocorrência separada de Git LFS e carregamento de arquivos por API.
- O CircleCI encontrou pipelines que não começaram ou permaneceram presos como ativos. A OpenAI relatou falhas e atrasos em trabalhos de programação dependentes do GitHub.
- O Actions foi considerado totalmente recuperado às 04h43 UTC, e o incidente terminou um minuto depois. A análise detalhada prometida pelo GitHub ainda não existia no fechamento deste brefing.
O código pode chegar ao repositório, a máquina de execução pode continuar ligada e, ainda assim, a entrega não sair do lugar.
Foi essa separação que a ocorrência do GitHub tornou visível. O primeiro aviso, às 23h34 UTC de domingo, tratava de desempenho degradado no Actions. Em seguida, a empresa informou que novos fluxos podiam atrasar ou deixar de iniciar e que trabalhos em andamento podiam falhar. Às 23h57, disse ter identificado a causa e iniciado a restauração, sem explicar qual componente havia falhado.
O alcance cresceu depois da meia-noite. API Requests entrou em interrupção parcial às 00h07. Pages e Issues apresentaram degradação. Outro registro de estado apontou falhas em operações Git LFS e no carregamento de arquivos por API. Às 01h11, o GitHub uniu o quadro: a indisponibilidade prolongada do Actions começara a produzir efeitos sobre outros serviços, e a ocorrência aberta à parte era relacionada.
A execução perdeu o comando antes de perder o código
O Actions não é apenas capacidade computacional alugada. Um evento no repositório dispara um fluxo, o fluxo cria tarefas, o sistema distribui essas tarefas a runners e devolve resultados às regras de merge, aos painéis e às integrações externas.
Cada uma dessas etapas pode terminar com uma versão diferente da realidade. O push existe, mas o pipeline não aparece. A tarefa executa, porém a verificação obrigatória não recebe o estado final. O arquivo grande permanece no LFS, enquanto a chamada usada para recuperá-lo falha. A página já publicada continua acessível, mas a próxima compilação do Pages não avança.
A ordem da recuperação mostra que as superfícies não voltaram juntas. Pages foi declarado normal às 01h37 e Issues, às 02h20. Às 02h43, o GitHub afirmou que Issues, API Requests e Pages haviam se recuperado, mas ainda trabalhava em tarefas do Actions que utilizavam runners autogerenciados ou runners hospedados de maior porte. API Requests voltou à normalidade às 03h03. O Actions passou a monitoramento às 03h34 e teve recuperação completa anunciada às 04h43.
Esses horários pertencem às comunicações do fornecedor. Eles não medem a indisponibilidade de todas as contas. O GitHub não divulgou quantidade de repositórios, organizações, tarefas, regiões ou taxa global de falhas. Uma equipe que usou somente operações Git pode ter vivido algo muito diferente de outra que dependia de Actions, LFS, Pages e serviços externos ao mesmo tempo.
O CircleCI expôs a divergência entre plataformas
O registro do CircleCI descreve o efeito operacional com precisão. A empresa atribuiu aos erros da API do GitHub fluxos que não iniciavam ou continuavam marcados como em execução. Também observou falhas no processamento de webhooks gerados por eventos de push.
Depois da recuperação da taxa de erros, o CircleCI orientou clientes a disparar novamente os pipelines que não começaram e a cancelar e repetir os que continuavam travados. A orientação revela que a recuperação do serviço de origem não corrigiu automaticamente o histórico mantido pelo serviço dependente.
A OpenAI forneceu outra confirmação independente. Seu registro associou falhas ou atrasos em fluxos de programação dependentes do GitHub à interrupção parcial das APIs e à degradação do Actions. Não há número de usuários, tarefas ou prejuízo financeiro. O dado importante é mais estreito: a ocorrência atravessou a fronteira do GitHub e apareceu em uma interface mantida por outra empresa.
Essas evidências não tornam CircleCI ou OpenAI responsáveis pela origem. Também não provam que todas as integrações falharam. Elas mostram que, quando o estado de uma entrega está dividido entre plataformas, o sinal verde no serviço de origem é apenas o início da recuperação.
Runner próprio não significa orquestração própria
O GitHub define um runner autogerenciado como uma máquina implantada e administrada pelo cliente para executar tarefas do Actions. A organização escolhe hardware, sistema operacional e ferramentas e assume o custo de manutenção.
Esse controle é útil para rede interna, requisitos de localização, segurança, capacidade ou hardware especializado. Ele não transfere ao cliente todo o plano de comando do fluxo.
O GitHub disse que ainda restaurava trabalhos executados em runners autogerenciados e em runners hospedados maiores depois que Issues, APIs e Pages já haviam voltado. Não afirmou que as máquinas dos clientes estavam quebradas. O ponto é outro: recursos computacionais disponíveis continuam esperando se evento, fila, distribuição da tarefa ou retorno de estado dependem do GitHub.
Uma rota de emergência precisa definir mais do que um servidor reserva. Quem pode iniciar a tarefa quando o disparo normal falha? Qual versão está autorizada? Como a aprovação é registrada? Onde o resultado final será preservado? Replicar apenas a execução cria capacidade ociosa de contingência, não uma cadeia de entrega independente.
Reexecutar exige conferir o que já mudou
Uma tarefa exibida como falha ou ativa pode já ter produzido efeito fora da plataforma. Ela pode ter publicado um pacote, alterado infraestrutura, enviado uma notificação ou iniciado uma implantação antes de perder a confirmação.
Repeti-la sem verificação pode duplicar a ação. A sequência mais segura é comparar o evento do repositório, o histórico do Actions, os registros do runner, os artefatos e o sistema de destino. Operações idempotentes e identificadores verificáveis de versão reduzem o risco, mas não dispensam a conferência.
A recomendação do CircleCI para cancelar e repetir corresponde ao estado observado em sua plataforma. Cada cliente ainda precisa saber o que existe dentro do próprio pipeline. Um teste interrompido costuma ser simples de repetir; uma mudança de produção aplicada parcialmente exige recuperação baseada no estado real do destino.
Falta explicar por que o problema se espalhou
O GitHub encerrou a ocorrência às 04h44 e prometeu uma análise detalhada. A linha do tempo pública mostra os componentes afetados e a ordem da recuperação, mas não revela o elemento inicial, o caminho que levou o impacto às APIs e aos demais serviços nem a mudança que evitará recorrência.
Também não há base para afirmar invasão, perda de código, perda de dados, falha de uma implantação específica, concentração geográfica ou crédito automático de SLA. A classificação critical pertence ao sistema de impacto do GitHub; não é medida do prejuízo de cada cliente.
A próxima divulgação útil deve separar a falha original, o acúmulo de tarefas e os efeitos secundários da restauração. Até lá, a conclusão deve permanecer operacional: o GitHub recuperou a cadeia de serviços, mas cada organização precisa reconciliar evento, execução e destino antes de encerrar a própria ocorrência.