Em 17 de agosto de 2026, o GitHub sofreu uma queda global que durou mais de sete horas, afetando o site e o GitHub Copilot. Para quem trabalha com software, a interrupção não significou apenas encontrar uma página indisponível, mas perder temporariamente uma parte da rotina em que código, colaboração e automação costumam se encaixar quase sem ruído. A segunda-feira dos desenvolvedores ficou mais longa porque uma ferramenta de trabalho virou, por algumas horas, uma porta fechada. O episódio ajuda a entender o tamanho da dependência criada em torno da plataforma e por que uma falha de infraestrutura pode atravessar tarefas que, para o usuário, parecem independentes.

Uma queda que atravessou o dia de trabalho

O incidente teve início às 6h40 (horário do Pacífico) e foi declarado como resolvido às 14h15. O período descrito pelo relato da GeekWire transforma a expressão “instabilidade global” em uma sequência concreta de horas nas quais diferentes equipes precisaram acompanhar a recuperação em vez de simplesmente continuar suas tarefas. A empresa informou que identificou a causa na manhã de segunda-feira, mas trabalhou durante a tarde para resolver falhas de login espalhadas. O problema, portanto, não terminou no momento em que a origem foi localizada. A correção ainda precisou alcançar uma série de acessos que continuavam falhando, e esse detalhe conduz à dimensão operacional do apagão.

O serviço confirmou a investigação às 9h40 EDT. Às 11h42 EDT, a empresa realizava mitigações, com taxas de erro permanecendo em 20% para web/API e 50% para downloads de repositórios. A API, sigla para a interface que permite a comunicação entre sistemas, é especialmente relevante porque muitos fluxos de desenvolvimento não dependem apenas do navegador: ferramentas e serviços automatizados também fazem solicitações por esse canal. Quando a falha alcança a web e a API ao mesmo tempo, o usuário vê o problema na tela e também nos processos que trabalham nos bastidores. A diferença entre os indicadores ainda mostra que a recuperação não ocorreu de maneira uniforme.

A taxa de erro chegou a 50% em downloads de arquivos e repositórios. Esse número desenha uma dificuldade diferente daquela percebida por quem apenas tenta abrir uma página, pois baixar um repositório é uma ação diretamente ligada ao acesso ao material que será estudado, revisado ou modificado. O GitHub não é somente um lugar para consultar projetos; seus arquivos também alimentam ambientes locais de desenvolvimento e tarefas de colaboração. Uma taxa de erro desse tamanho transforma uma operação aparentemente simples em uma sequência de tentativas, esperas e verificações. É por isso que a interrupção alcançou o cotidiano de quem precisava recuperar código, e não apenas a vitrine visual do serviço.

Quando o código deixa de circular

A interrupção afetou ferramentas de revisão de código e sistemas de CI/CD. A sigla descreve processos usados para automatizar etapas de integração, teste e entrega de software, de modo que uma alteração possa passar por verificações antes de chegar a outros ambientes. Quando esses mecanismos ficam instáveis, o impacto não se limita ao desenvolvedor que está olhando para uma tela: uma mudança pode aguardar validação, uma revisão pode não avançar e uma sequência automatizada pode perder o ritmo. O trabalho continua existindo, mas deixa de circular na velocidade esperada. Essa fricção ajuda a explicar por que horas de indisponibilidade podem produzir efeitos muito maiores do que o tempo indicado no relógio.

Serviços de autenticação como SAML e OIDC também foram afetados. Em termos práticos, esses mecanismos participam da confirmação de identidade e do controle de acesso, permitindo que uma pessoa ou uma organização prove quem é antes de entrar em determinado recurso. Uma falha nessa camada pode atingir usuários que não perderam seus projetos, mas perderam a capacidade de alcançá-los no momento necessário. O código pode continuar armazenado, enquanto a chave digital para chegar até ele deixa de responder. As falhas de login espalhadas mencionadas pela empresa tornam essa diferença entre possuir um recurso e conseguir utilizá-lo ainda mais concreta.

SCIM e Team Sync também apareceram entre os serviços atingidos. O primeiro nome está ligado à sincronização de identidades e permissões, enquanto o segundo se refere à coordenação de integrantes dentro de equipes, funções que organizam quem pode acessar determinados espaços e como esse acesso é atualizado. Não se trata, portanto, de uma interrupção restrita a uma pessoa diante do próprio projeto, mas de uma perturbação que alcançou relações de acesso administradas por grupos. Em uma plataforma colaborativa, a disponibilidade precisa incluir tanto o arquivo quanto as pessoas autorizadas a trabalhar nele. A falha nesses mecanismos prepara o caminho para entender também o que permaneceu funcionando durante o evento.

Serviços como Git Operations e Packages mantiveram-se operacionais durante o evento. Essa informação, registrada no status do GitHub, impede uma leitura simplista de que cada parte da plataforma caiu da mesma maneira e ao mesmo tempo. Git Operations está ligado às operações realizadas com repositórios, enquanto Packages atende ao armazenamento e à distribuição de pacotes utilizados por projetos. A experiência da queda foi desigual, e essa desigualdade importa para quem precisa separar uma tarefa interrompida de outra que ainda pode prosseguir. A recuperação e a continuidade de alguns componentes aparecem com mais clareza quando se observam outros serviços citados no mesmo registro.

O mesmo relato informa que Pages e Codespaces também permaneceram operacionais. A permanência desses serviços não elimina os problemas registrados em outras áreas, mas mostra que a interrupção teve fronteiras técnicas específicas, ainda que o efeito geral tenha sido percebido em escala global. Para o usuário, essa distinção pode ser difícil de enxergar, porque a plataforma é apresentada como uma experiência única, embora seja formada por várias camadas e funções. O botão que falha é apenas a superfície de uma arquitetura que pode continuar respondendo em um ponto e parar em outro. Essa arquitetura fragmentada também ajuda a explicar por que o Copilot apareceu como uma das faces mais visíveis da instabilidade.

O Copilot expõe a pressão da inteligência artificial

O GitHub Copilot teve disponibilidade degradada confirmada às 10h31 EDT. O assistente de codificação por inteligência artificial ocupa uma posição diferente de uma simples página de consulta, porque participa diretamente da produção de sugestões durante o trabalho de programação. Quando ele deixa de responder ou funciona de maneira irregular, o desenvolvedor pode continuar escrevendo código, mas perde uma ferramenta integrada ao fluxo que escolheu utilizar. A interrupção colocou em pausa uma promessa típica da automação: a ideia de que a assistência digital estará presente justamente quando o trabalho exigir uma resposta rápida. O horário registrado para a degradação também mostra que o Copilot não ficou fora da história principal do apagão, mas dentro dela.

O CTO Vladimir Fedorov mencionou anteriormente a necessidade de expandir a capacidade do GitHub em 30 vezes devido ao aumento de ferramentas de IA. A declaração oferece uma chave para ler o episódio sem reduzi-lo a um acidente isolado, embora as fontes não apresentem, neste caso, uma explicação técnica detalhada para cada falha registrada em agosto. A expansão indicada não aparece como um pequeno ajuste, mas como uma medida de escala que acompanha a multiplicação de usos associados à inteligência artificial. Quanto mais funções passam a depender de respostas automáticas, maior fica a distância entre uma plataforma popular e a infraestrutura necessária para sustentá-la. O histórico de fevereiro mostra que essa pressão já vinha acompanhada de interrupções relevantes.

Agosto veio depois de outros incidentes

Em 2 de fevereiro, uma falha em políticas de segurança de provedor de computação afetou o GitHub Actions e o Copilot por quase seis horas. O dado consta no relatório oficial de disponibilidade do GitHub, que reúne os incidentes daquele mês e permite comparar a queda de agosto com problemas anteriores. O GitHub Actions automatiza tarefas definidas para um projeto, enquanto o Copilot atua como assistente de programação, e os dois serviços atingidos pertencem a momentos diferentes do mesmo fluxo de trabalho. Quando uma falha externa alcança automação e assistência, o desenvolvedor percebe que sua produtividade depende de camadas que nem sempre controla. A lista de fevereiro ainda inclui outro componente afetado na mesma ocorrência.

O incidente de 2 de fevereiro também afetou o Codespaces por quase seis horas. O serviço oferece um ambiente de desenvolvimento hospedado, o que permite trabalhar com um projeto sem depender exclusivamente da configuração local da máquina, e sua inclusão no relatório amplia a dimensão daquele episódio. A causa descrita foi uma falha em políticas de segurança de um provedor de computação, não uma alteração feita pelo usuário em seu próprio código. Para quem trabalha à distância de uma infraestrutura hospedada, a fronteira entre o ambiente de programação e o provedor que o sustenta pode desaparecer no momento da interrupção. Nove dias depois, o relatório registrou uma causa de outra natureza, ligada a configurações internas.

Em 9 de fevereiro, dois incidentes, totalizando 2h43, foram causados por alterações de configuração em mecanismos de cache de usuários, gerando exaustão de conexão no proxy Git HTTPS. Cache é uma forma de guardar dados temporariamente para acelerar acessos futuros, enquanto um proxy funciona como intermediário entre solicitações e serviços; quando as conexões disponíveis se esgotam, o intermediário deixa de atender parte do tráfego. O registro oficial não coloca esse episódio na mesma causa da queda de agosto, mas mostra que a plataforma enfrentou problemas distintos ao longo do ano. A repetição de interrupções com origens diferentes torna a pergunta mais incômoda: como medir a confiança em um serviço que cresce mais depressa do que sua margem para falhar?

O que muda para quem depende do GitHub

O status do GitHub indicou que as requisições de API voltaram a operar normalmente após a mitigação das falhas. A empresa trabalhou na desativação parcial de retentativas de tokens de autenticação para estabilizar o sistema, uma decisão que mostra como a recuperação exigiu interferir no comportamento das próprias tentativas de acesso. Em vez de simplesmente religar uma chave, a equipe precisou reduzir parte do fluxo de novas solicitações para evitar pressão adicional sobre a infraestrutura. A restauração, nesse caso, foi uma operação de equilíbrio entre aceitar tráfego e impedir que novas tentativas agravassem a instabilidade. Esse detalhe técnico traduz o problema para uma imagem cotidiana: às vezes, para reabrir uma passagem, é preciso controlar a fila que se forma diante dela.

O dado concreto que fica para o próximo uso é este: as requisições de API voltaram a operar normalmente após a mitigação, enquanto os downloads chegaram a 50% de erro durante a crise. Para equipes e profissionais, a lição prática é não tratar a disponibilidade da página principal como sinônimo de funcionamento completo: revisão, autenticação, automação, downloads e assistência por IA podem ter comportamentos diferentes, como os registros de 17 de agosto mostraram. A caixa de ferramentas começa por distinguir qual parte do serviço está falhando antes de concluir que todo o trabalho precisa parar. A plataforma foi declarada resolvida às 14h15, mas a discussão sobre ampliar sua capacidade em 30 vezes continua sendo o próximo ponto concreto para acompanhar, porque é ali que a promessa de uma programação cada vez mais assistida por IA encontra o limite físico da infraestrutura.