--- title: "GitHub caiu em escala global e a segunda-feira dos devs ficou longa demais" author: "Lígia Lemos Maia" date: "2026-08-19 07:00:00-03" category: "Tecnologia & Desenvolvimento" url: "http://desbugados.scale.press/portal/desbugados/post/2026/08/19/github-caiu-em-escala-global-e-a-segunda-feira-dos-devs-ficou-longa-demais/md" --- ## Resumo - A queda global do GitHub em 17 de agosto de 2026 durou mais de sete horas. - O incidente começou às 6h40 no horário do Pacífico e só foi declarado resolvido às 14h15. - As taxas de erro chegaram a 20% no tráfego web e de API e a 50% nos downloads de arquivos e repositórios. - Revisão de código, CI/CD, autenticação e GitHub Copilot foram afetados, enquanto alguns serviços permaneceram operacionais. - O Copilot teve disponibilidade degradada, e o CTO Vladimir Fedorov já havia mencionado a necessidade de ampliar a capacidade do GitHub em 30 vezes. - O apagão ocorreu após outros incidentes registrados em fevereiro de 2026, incluindo falhas que duraram quase seis horas e 2h43. - A recuperação envolveu mitigações e a desativação parcial de retentativas de tokens de autenticação. --- 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](https://www.geekwire.com/2026/github-outage-disrupts-developers-worldwide-in-latest-setback-for-microsoft-coding-platform/) 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](https://github.blog/news-insights/company-news/github-availability-report-february-2026/), 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.