No dia 17 de agosto de 2026, o GitHub ficou parcialmente fora do ar por 7 horas e 47 minutos, das 13h28 às 21h15 UTC. A taxa de erro chegou a 20% no site e na API, e a 50% em downloads de arquivos e repositórios inteiros. Autenticação corporativa (SAML e OIDC), sincronização de equipes (SCIM) e o Copilot também foram afetados, travando login, deploy, revisão de código e sessões de programação assistida por IA ao mesmo tempo, no mundo inteiro.

Foi o quinto incidente notável do GitHub em três semanas: 29 de julho (timeouts na API do Actions por um serviço interno subdimensionado), 30 de julho (modelo de IA do Copilot degradado por 73 minutos), 10 de agosto (falha na criação de tokens de acesso), 13 de agosto (sincronização corporativa interrompida e novo erro no Copilot) e o apagão de 17 de agosto.

A causa raiz, publicada pelo próprio GitHub, é o tipo de coisa que só quem mantém sistema maduro reconhece na hora: uma política de autoscaling que vigiava o limite de um serviço, mas não o limite do sidecar do Istio, a camada de rede que roda junto de cada serviço. Quando o tráfego bateu um novo pico, o sidecar não escalou, um balanceador de carga sufocou, depois outro, até quatro nós HAProxy ficarem sem capacidade e travarem a autenticação inteira. Um bug de retry já existente no VS Code amplificou o problema em cerca de dez vezes, e o tráfego do serviço de token do Copilot saltou de 7 a 9 mil requisições por segundo para até 100 mil.

Por que isso interessa a quem sustenta sistemas maduros em escala: nada disso era um bug óbvio. Era uma pilha de decisões antigas e razoáveis, uma política de autoscaling, uma lógica de retry, que ninguém tinha motivo pra revisar, até um tipo novo de tráfego empurrar o sistema pra um canto que nunca tinha sido testado.

Como a queda foi contida

O relatório de incidente do GitHub detalha a recuperação: pausar ao mesmo tempo os quatro nós HAProxy afetados, reduzir a lógica de retry nos gateways e bloquear temporariamente pedidos de token do Copilot, liberando o tráfego aos poucos até a estabilização completa, por volta das 21h02 UTC.

Não foi só o GitHub

Um dia antes, em 16 de agosto, a Anthropic também teve uma falha: 36 minutos de autenticação fora do ar no claude.ai, na API, no Claude Code e no Cowork. Foi o segundo incidente notável da Anthropic em cerca de três semanas, depois de uma falha de rede de quase 24 horas em 29 e 30 de julho. Nenhuma das duas empresas divulgou publicamente uma causa raiz completa para seus próprios incidentes de IA generativa, só o GitHub detalhou a cadeia técnica da própria queda.

O tamanho da exposição, em números

– O GitHub tem mais de 180 milhões de desenvolvedores cadastrados, segundo o relatório Octoverse 2025 da própria empresa.

– 36 milhões de novos desenvolvedores entraram na plataforma em 2025, mais de um por segundo.

– 80% dos novos desenvolvedores começam a usar o Copilot na primeira semana de uso.

“A causa imediata da falha foi saturação de rede nos balanceadores de carga na região Central dos Estados Unidos, devido a um novo pico de tráfego”, diz o relatório de incidente publicado pelo GitHub, que também cita o tráfego do serviço de token do Copilot como o principal amplificador do problema.

LIMITE DA EVIDÊNCIA

o texto completo do relatório de incidente do GitHub circulou publicamente por meio de cobertura de terceiros e de um comentário reproduzindo o conteúdo do status page da empresa, não por um post oficial no blog corporativo do GitHub até o momento desta matéria. Vale conferir se a empresa publica uma versão formal e mais detalhada do post mortem nos próprios canais. Também não há dado público confirmando o impacto financeiro do apagão para clientes empresariais do GitHub.

NOSSA LEITURA

 Achamos que o detalhe mais revelador não é a queda em si, é a causa: uma política de autoscaling que existia há tempos e nunca tinha sido testada contra esse tipo específico de pico. Nossa aposta é que o crescimento acelerado de tráfego de IA (Copilot incluído) vai continuar expondo esse tipo de suposição antiga em infraestrutura madura, no GitHub e em qualquer empresa que rode sistemas críticos há anos sem revisar política de capacidade linha por linha. Vale observar se o GitHub e a Anthropic tratam esse mês como gatilho pra auditoria de fundo, ou só corrigem o item específico que falhou dessa vez.

IMPLICAÇÃO PRO GESTOR

Se sua empresa depende de uma plataforma madura (interna ou de terceiros) que nunca foi testada contra um pico de tráfego real, a pergunta não é “isso já falhou antes” e sim “que política de configuração ninguém revisa porque sempre funcionou”. O caso GitHub mostra que o ponto de ruptura pode estar numa única linha de configuração, e vale mapear com seu time quais dessas linhas existem no seu ambiente antes que um pico as encontre primeiro.

A linha de configuração que faltou revisar no GitHub existe, quase certamente, em algum sistema que você mantém também. Se vigiar esse tipo de ponto cego é o que te move de verdade, descubra fazendo o Teste de Arquétipo, e receba esse tipo de leitura cruzada com seu arquétipo toda semana assinando o Boletim.