Interrupção do GitHub causada por aumento de tráfego impulsionado por IA e erro de configuração

Em 9 de fevereiro deste ano, na madrugada, horário de Pequim, dezenas de milhões de desenvolvedores em todo o mundo abriram o GitHub e viram a mesma página.

Não é 404, é algo mais ansioso do que 404 — é aquela faixa amarela de aviso que faz todos os engenheiros sentirem arrepios na nuca, junto com uma série de luzes na página de status que mudam de verde para vermelho.

github.com está fora do ar.

A API está fora do ar.

GitHub Actions está fora do ar.

As operações do Git falharam — nem o Copilot pôde escapar.

Naquela noite, a linha CI/CD de alguém parou no ponto mais crítico, a implantação automatizada de alguém ficou suspensa no ar e alguém aguardava um PR que nunca era mesclado—por trás disso estava uma funcionalidade aguardando o lançamento, esperando pelos usuários reais.

Após o evento, o GitHub publicou um relatório de incidente. A causa raiz, em termos técnicos, foi "um cluster de banco de dados central responsável por autenticação e gerenciamento de usuários sobrecarregado". Mas por trás dessas palavras esconde-se uma cadeia de gatilhos alarmante—

Há dois dias, a equipe de engenharia alterou o tempo de atualização do cache de configurações do usuário de 12 horas para 2 horas, a fim de disponibilizar rapidamente um novo modelo para os usuários. Foi apenas essa alteração em um único valor de configuração.

Como resultado, a reescrita de cache, que originalmente estava distribuída ao longo de 12 horas, foi comprimida em apenas 2 horas, criando uma "tempestade de reescrita de cache" intensa. A fila de tarefas assíncronas foi sobrecarregada instantaneamente, os componentes da infraestrutura compartilhada entraram em colapso, e a reação em cadeia se espalhou para o serviço responsável pelas operações HTTPS Git de proxy, resultando finalmente no esgotamento de todas as conexões da plataforma.

Um número alterado de 12 para 2.

GitHub foi derrubado por uma configuração que eu mesmo modifiquei.

Mas se você só viu essa única alteração de configuração, provavelmente perdeu a parte mais importante dessa história.

O incidente de 9 de fevereiro não é um evento isolado.

Na verdade, nos três primeiros meses de 2026, o GitHub sofreu pelo menos oito grandes incidentes. Em fevereiro, foram registrados 37 falhas, grandes e pequenas. O CTO do GitHub, Vlad Fedorov, posteriormente admitiu em um blog que, durante esses dois meses, o GitHub não conseguiu manter a disponibilidade de "três noves" — 99,9% — prometida aos clientes corporativos.

Ao revisar os arquivos de falhas dos últimos dois meses, você encontrará um padrão estranho: cada incidente parece ter uma causa diferente.

2 de fevereiro: Problema com o provedor de computação da Azure, causando interrupção de quase 4 horas no GitHub Actions, afetando o Copilot, CodeQL e Dependabot.

9 de fevereiro: tempestade de reescrita de cache, banco de dados de autenticação sobrecarregado.

5 de março: Falha no cluster Redis; 95% dos fluxos de trabalho do GitHub Actions não conseguiram iniciar em 5 minutos, com atraso médio de 30 minutos.

18 de março: A latência do webhook aumentou para 32 vezes o nível normal.

Cada incidente parece ser um "acidente", e cada causa direta é diferente. Mas a explicação de Fedorov os conecta em uma única narrativa. Ele disse que há três razões estruturais comuns por trás desses acidentes: "crescimento rápido da carga, acoplamento apertado entre serviços que leva à propagação de falhas locais e falta de proteção do sistema contra tráfego de clientes anômalos."

Em termos de engenheiro, a fundação do GitHub já começou a rachar sob a pressão de novas cargas.

E esse "novo carregamento" tem um nome específico.

Dados principais

Volume total de commits ao longo de 2025: aproximadamente 1 bilhão

Quantidade semanal de commits em 2026: 275 milhões

Nesta taxa, a previsão para todo o ano de 2026 é de 14 bilhões (aumento de 14 vezes em relação ao ano anterior)

Quantidade de cálculo do GitHub Actions: 500 milhões de minutos por semana em 2023 → 1 bilhão em 2025 → 2,1 bilhões de minutos em alguma semana no início de 2026

Se você fosse engenheiro de infraestrutura do GitHub, a comparação dos painéis de monitoramento de 2025 e 2026 provavelmente o deixaria de boca aberta.

Em todo o ano de 2025, o GitHub processou cerca de 1 bilhão de commits. Esse número, por si só, já é enorme, resultado de anos de acúmulo na plataforma GitHub. Mas em 2026, o número de commits em uma única semana atingiu 275 milhões. Convertendo isso — se essa taxa for mantida durante todo o ano, o total de commits em 2026 chegará a quase 14 bilhões, exatamente 14 vezes o total de 2025.

Esta não é uma curva de crescimento suave, mas sim uma inclinação acentuada. A variação no volume de cálculos do GitHub Actions ilustra melhor isso: em 2023, foram consumidos 500 milhões de minutos por semana, em 2025 dobrou para 1 bilhão, e em alguma semana no início de 2026, subiu diretamente para 2,1 bilhões de minutos.

O que está enviando código loucamente?

Não é um desenvolvedor humano.

Os dados do GitHub mostram que os AI Agents estão se tornando o “usuário” mais ativo nesta plataforma. Apenas a ferramenta Claude Code agora representa 4,5% de todos os commits nos repositórios públicos do GitHub. São 2,6 milhões de commits por semana, enquanto em setembro de 2025 eram apenas 100 mil — um aumento de 25 vezes em três meses.

O número de PRs abertos por agentes de IA também está explodindo. Em setembro de 2025, os PRs gerados por IA eram cerca de 4 milhões por mês; até março de 2026, esse número saltou para 17 milhões — mais de quatro vezes, em seis meses.

Há uma imagem que pode ajudá-lo a entender o que isso significa.

Antes, os "usuários" do GitHub eram principalmente programadores humanos. Eles trabalhavam durante o dia, dormiam à noite, descansavam nos fins de semana, refletiam e hesitavam em cada commit, e tinham um limite de velocidade manual. A carga do sistema seguia o ritmo humano, apresentando picos e vales previsíveis.

Atualmente, um número crescente de "usuários" são Agentes de IA. Eles não dormem, não descansam, não hesitam; é possível executar múltiplos Agentes em paralelo para uma única tarefa, e cada Agente pode submeter volumes por hora que facilmente superam o trabalho semanal de um engenheiro real. Mais importante ainda, eles não estão apenas enviando código, mas também criando continuamente novos repositórios — tratando os repositórios como "produtos de saída" do fluxo de trabalho, e não como "espaços de trabalho" humanos.

Os engenheiros de infraestrutura do GitHub enfrentam não um problema similar com maior tráfego, mas um problema de natureza completamente diferente.

As falhas frequentes são apenas um lado do problema; o GitHub também tem outro problema mais preocupante — ao fazer a contabilidade, descobre-se que houve prejuízo.

A lógica de precificação original do Copilot foi baseada em uma suposição razoável: os usuários utilizavam principalmente para complementação assistida, com cada interação sendo breve e o consumo de computação previsível. O modelo de US$ 10 por mês para a versão pessoal e US$ 19 por mês para a versão comercial, cobrado por assento, funcionou bem nos últimos anos.

Then, Agentic AI arrived.

Fluxos agênticos e preenchimento tradicional são duas espécies diferentes. O preenchimento padrão de código tem solicitações lineares e previsíveis, com ciclos de cálculo curtos. Já uma sessão de codificação agêntica pode durar várias horas, iniciando múltiplos threads em paralelo, realizando raciocínio em várias etapas, autocorreção e refatoração entre repositórios — uma única sessão consome uma quantidade de tokens que facilmente supera a assinatura mensal de um usuário comum.

O GitHub enfrenta a situação em que um pequeno número de usuários intensivos de Agentic estão consumindo recursos de computação equivalentes a centenas de dólares, pagando apenas alguns dólares por mês.

Diante dessa situação, a reação do GitHub foi direta — primeiro, controlar o fluxo, depois ajustar o preço.

No início deste ano, o GitHub implementou dois conjuntos paralelos de limites de taxa para o Copilot: limite de duração da sessão e limite de uso semanal, ambos calculados com base no consumo de tokens multiplicado pelo peso de cálculo do modelo. Ao mesmo tempo, a inscrição de novos usuários foi suspensa para alguns planos individuais do Copilot.

Em 1º de junho, o GitHub implementou uma reforma de preços mais fundamental: o Copilot passou totalmente para o modelo de cobrança por uso, substituindo os planos anteriores por "AI Credits", onde 1 AI Credit equivale a 1 centavo de dólar, com o uso calculado em tempo real com base no consumo de tokens.

A era de cobrança por assento chegou ao fim diante da IA Agente.

Essa transformação não é apenas um problema do GitHub. É uma crise coletiva de precificação que toda a indústria de ferramentas de IA está enfrentando em 2026 — quando a IA começar a substituir humanos na execução de fluxos de trabalho completos, e não apenas "auxiliar" o trabalho humano, toda lógica de assinatura baseada em "por pessoa por mês" deixará de funcionar.

Voltando ao problema da infraestrutura. O GitHub planeja lidar com esse "crescimento de 14 vezes" de que maneira?

Há um detalhe que ilustra a gravidade da situação:

No final de dezembro de 2025, os fluxos de trabalho Agentic começaram a acelerar repentinamente. Os engenheiros do GitHub perceberam que dez vezes não era suficiente. Em fevereiro de 2026, após aquela interrupção grave, o GitHub anunciou a necessidade de redesenhar sua arquitetura para ser 30 vezes maior que a escala atual.

Não é uma expansão, é um redesenho.

A diferença entre esses dois termos é grande. Escalar significa aumentar o número de máquinas existentes ou adicionar mais memória ao banco de dados existente — a direção permanece a mesma, apenas a escala aumenta. Reprojeto significa que os pressupostos da arquitetura atual falharão sistematicamente em uma escala 30 vezes maior, exigindo uma reavaliação fundamental da divisão de serviços, do fluxo de dados e da isolamento de falhas.

As direções específicas divulgadas pelo GitHub incluem: desacoplar serviços críticos para evitar falhas em cascata, introduzir mecanismos de backpressure e capacidade de degradação de tráfego, implantar servidores dedicados para serviços populares, eliminar pontos únicos de falha e implementar um gerenciamento de mudanças mais robusto — evitando operações como "alterar o TTL do cache de 12 horas para 2 horas" sem testes de carga adequados antes da implantação.

É importante notar que o GitHub não está sozinho.

Stripe já enfrentou o problema de criação em massa de contas por Agentes de IA; a AWS está construindo sistemas dedicados de identidade, log e controle de produção para Agentes. Essas ações não são preventivas, mas sim uma resposta a sinais já visíveis nos painéis de monitoramento que precisam ser resolvidos.

O GitHub foi apenas o primeiro a ser comprometido — porque está no núcleo mais central da cadeia de ferramentas de IA.

Pare e pense sobre a natureza de todo esse evento.

O que é o GitHub? A resposta mais direta é que é o lugar onde programadores armazenam seu código. Mas, mais profundamente, é a infraestrutura de colaboração de software humana — commits são a trajetória da colaboração, PRs são recipientes de discussão, Issues são o registro de intenções e Actions são canais de execução. Todo o sistema foi projetado para o ritmo de trabalho, o pensamento e os padrões de colaboração humanos.

O Agente de IA mudou tudo.

Quando um agente de IA pode enviar códigos centenas de vezes por dia, e cada “envio” não é acompanhado por pensamento ou ponderação humana, mas apenas por um passo de progresso em um ciclo de tarefas — o repositório de código ainda é um “contêiner de colaboração”?

Quando ferramentas de IA geram repositórios automaticamente, abrem PRs automaticamente, executam CI automaticamente e fazem merge automaticamente — os desenvolvedores ainda são os principais atores nesse fluxo, ou já se tornaram meros “revisores” ou até “espectadores”?

O CTO do GitHub, ao descrever essa crise, usou a expressão “crescimento rápido da carga”. Mas essa expressão provavelmente subestima a natureza do problema — não se trata apenas de um aumento quantitativo, mas de uma mudança qualitativa no modo de uso. No modelo antigo, o GitHub era uma “ferramenta para desenvolvedores”; no novo modelo, o GitHub está se tornando um “exaustor da IA”, um canal de saída para fluxos de trabalho automatizados.

Isso ainda não tem resposta para o GitHub. Um aumento de 30 vezes pode resolver problemas de tráfego, mas não resolve a redefinição do modelo de negócios nem a questão de identidade: “Quem são meus verdadeiros usuários?”.

Recentemente, observou-se um fenômeno bastante significativo: após uma interrupção, o GitHub publicou uma série de blogs técnicos, descrevendo detalhadamente as causas raiz de cada incidente, alcançando um nível de transparência quase surpreendente. Alguns acreditam que o GitHub está ativamente construindo confiança, enquanto outros acham que está trocando transparência pela paciência da comunidade de desenvolvedores — pois um período de reestruturação ainda mais instável está por vir.

Uma plataforma que, após ser perfurada pelo próprio sucesso, precisa se desmontar e reconstruir—e esse processo, por si só, é um teste de sua capacidade de resistir.

Na noite de 9 de fevereiro, o engenheiro que aguardava a fusão do PR provavelmente acabou recebendo o sinal verde. Mas ele pode não ter percebido que o downtime que o fez esperar não foi um acidente do GitHub, mas sim um sinal de que toda a indústria de desenvolvimento de software entrava em uma nova era.

Este artigo é do公众号 "GeekPark" (ID: geekpark), autor: AstronautMonkey