A GitHub revelou detalhes de cinco incidentes que afetaram a disponibilidade de seus serviços durante agosto de 2026, incluindo falhas no GitHub Actions, atrasos nos resultados do Copilot Cloud Agent e falhas em solicitações ao modelo Kimi K3. A empresa relaciona os incidentes ao crescimento da plataforma e às margens reduzidas de capacidade, além de falhas na escalabilidade automática, nas políticas de novas tentativas e nos mecanismos de recuperação.
A GitHub afirma que está investindo na melhoria da arquitetura e migrando mais serviços para o Azure, priorizando a disponibilidade, depois a capacidade e, por fim, os recursos. A empresa também anunciou melhorias no monitoramento da capacidade, no gerenciamento de filas, nas políticas de novas tentativas e na resiliência dos serviços essenciais.
Cinco incidentes com causas diferentes
- 6 de agosto: o incidente durou 10 horas e 42 minutos, depois que uma implantação rotineira de um serviço interno no Actions reduziu temporariamente a capacidade em uma das localidades. Isso causou a saturação dos serviços e a propagação de erros para o cache, o DNS e as APIs, e uma falha no caminho de atribuição de tarefas atrasou o processo de recuperação. Uma grande parcela dos workflows falhou ou sofreu atrasos, e alguns eventos precisaram ser reiniciados manualmente.
- 17 de agosto: a degradação durou 7 horas e 35 minutos devido ao fato de os balanceadores de carga em um data center terem atingido o pico de sua capacidade, enquanto um componente secundário da rede de serviços não escalou apesar de atingir seu limite de concorrência. Isso causou atrasos e falhas no caminho compartilhado de autenticação, afetando também Issues, Pull Requests, APIs, Actions e Copilot. Uma falha nas novas tentativas também duplicou o tráfego de solicitações para um ponto de autenticação interno.
- 20 de agosto: o incidente durou 9 horas e 54 minutos e afetou o estado e os resultados das tarefas do Copilot Cloud Agent em pelo menos 54 organizações. Uma região do provedor de banco de dados em nuvem que armazena os estados das tarefas ficou indisponível, e a transferência regional falhou rapidamente devido a uma configuração de armazenamento, fazendo com que as atualizações de estado se acumulassem. As tarefas em si não foram perdidas, mas a exibição dos resultados atrasou até a restauração do processamento e o esvaziamento da fila.
- 26 de agosto: a degradação durou 2 horas e 50 minutos, quando uma carga de eventos levou um banco de dados compartilhado, que operava próximo ao seu limite, à saturação. Isso atrasou o início das operações do Actions, afetando serviços que dependem dele, como o Copilot Code Review e algumas operações do GitHub Pages. A GitHub precisou limitar gradualmente a carga recebida, pois não havia um disjuntor automático para ativar a proteção quando surgissem indicadores de estresse.
- 27 de agosto: o incidente durou 2 horas e 8 minutos e afetou apenas as solicitações direcionadas ao modelo Kimi K3 dentro do Copilot, devido à degradação no provedor externo do modelo. A taxa de falha dessas solicitações superou a metade no pico do incidente, enquanto os outros modelos e a configuração Auto permaneceram disponíveis.
O que mudou na prática?
As medidas anunciadas mostram que a GitHub está tratando os incidentes como problemas de capacidade, isolamento e recuperação, e não apenas como falhas de implantação isoladas. A empresa transferiu 33% das funções do Actions de um cluster de produção restrito para capacidade de reserva, reduzindo o uso do processador do cache no pico de 98% para 80% e acrescentando, segundo sua estimativa, cerca de três meses de margem. As leituras dos serviços migrados para o Azure também atingiram um pico de 60,4%, as do sistema monolítico chegaram a 64,3% e as do Git, a 54%.
No nível dos bancos de dados, o primeiro MySQL primary de produção no Azure foi ativado em 11 de agosto sem impacto perceptível nas operações de gravação observadas pelos clientes, e o padrão se repetiu com dois bancos de dados essenciais em 27 de agosto. A GitHub também removeu cerca de um milhão de consultas por segundo de réplicas de um banco de dados antigo, enquanto outras mudanças reduziram 120 mil consultas por segundo e cerca de 59 mil segundos de trabalho desperdiçado a cada hora.
Por que este relatório é importante?
Os incidentes mostram que depender apenas da escalabilidade horizontal não é suficiente quando os serviços compartilham bancos de dados, caminhos de autenticação ou uma infraestrutura única do Actions. Além disso, novas tentativas sem controle podem transformar uma degradação parcial em uma carga mais ampla, enquanto atrasos na transferência entre regiões podem fazer os estados se acumularem mesmo quando as tarefas originais não são perdidas. O plano para o Azure e as medidas de isolamento e os disjuntores de carga ainda estão em execução; portanto, o relatório não comprova que os riscos foram eliminados, mas esclarece onde a GitHub concentrará seus próximos trabalhos: migrar bancos de dados essenciais adicionais, automatizar o gerenciamento de capacidade e ampliar o tratamento de falhas de dependências.