O GitHub publicou seu relatório mensal de disponibilidade cobrindo agosto e setembro de 2026. Como em agosto não houve atualização em setembro, o documento resume dois meses de trabalho. A empresa diz que reduziu a pressão sobre bancos de dados compartilhados, adicionou controles contra sobrecarga, criou folga de capacidade para o GitHub Actions e avançou na migração de cargas de produção para a Azure. Ainda assim, a própria empresa admite que o trabalho não está completo.

Até 7 de outubro, 120 de 160 serviços de produção já estavam implantados na região Central US, e 13 de 51 bancos de dados MySQL primários haviam sido movidos. A Azure atendia 65,4% do tráfego de leitura da aplicação principal, 48,3% do tráfego de leitura do Git e 80,2% do tráfego de processamento de streams. São medições de cargas diferentes, por isso não devem ser somadas. Em 11 de setembro, o GitHub pausou novas implantações e aumentos de tráfego na Central US porque a capacidade estava desigual entre as zonas de disponibilidade. A meta de implantar todos os serviços até 30 de setembro não foi cumprida. Durante uma troca planejada de banco de dados, um processo automático de emergência desconectou cópias de bancos da região e afetou clientes; esse processo foi desativado nas trocas planejadas enquanto a recuperação é melhorada.

Fora da migração regional, 24 tabelas do núcleo de autenticação saíram do banco compartilhado mais antigo, retirando cerca de um milhão de consultas por segundo das réplicas. No banco que dá suporte a issues e pull requests, foram removidas cerca de 980 milhões de linhas desnecessárias de histórico de edições, liberando cerca de 1,8 terabyte de armazenamento. Os travamentos semanais caíram cerca de 77% em relação ao pico de junho. Também foi criada uma forma de as pull requests seguirem com funcionalidade limitada quando uma dependência compartilhada falha, metade do tráfego amostrado já pode fazer isso.

No GitHub Actions, mudanças em produção reduziram cerca de 28% as operações medidas no Redis e cerca de 30% a CPU relativa. Um cache de infraestrutura separado reduziu em 84% a banda do Redis e em 66% o tempo médio de resposta.

O relatório também descreve dois incidentes. Um deles começou com uma tarefa de limpeza de dados em segundo plano que sobrecarregou um banco compartilhado: ela tinha uma proteção para desacelerar quando as réplicas ficavam para trás, mas essa proteção não considerava a carga recebida pelo servidor principal. Além disso, faltava um tempo limite rápido nas chamadas ao banco e um laço de novas tentativas na criação de tokens reenviava gravações que já falhavam, mantendo o banco saturado. O outro incidente afetou a revisão de código do Copilot: uma mudança passou a enviar a versão completa do resultado só para alguns clientes, e para os demais chegava apenas a cópia limitada. Assim, as revisões não eram geradas, mas o sistema informava que o trabalho tinha terminado com sucesso. A falha só foi percebida porque algumas revisões ficaram incompletas por mais de 30 minutos. A solução foi reverter a mudança.

Para acompanhar atualizações em tempo real e os resumos pós-incidente, a fonte recomenda consultar a página de status oficial do GitHub. Para quem usa a plataforma, o recado é que a estabilidade continua em construção, e a empresa diz priorizar disponibilidade, depois capacidade e só então novos recursos.