GitHub quase 8 horas em baixo por causa das retries

O GitHub esteve em baixo quase 8 horas a 17 de agosto

O GitHub.com sofreu uma falha de 7 horas e 47 minutos a 17 de agosto de 2026, das 13:28 às 21:15 UTC, que degradou quase todos os fluxos de trabalho centrais dos programadores na plataforma. Erros e latências elevados afetaram em simultâneo Issues, Pull Requests, as API REST e GraphQL, o GitHub Actions e o GitHub Copilot, pelo que a interrupção não se limitou a uma única funcionalidade. O próprio post-mortem do GitHub, publicado no github.blog sob o título "The August 17 outage and the work ahead", situa a taxa máxima de erros em cerca de 20% em todo o site, e cerca de 50% especificamente em downloads de arquivos comprimidos e ficheiros raw. The Register, TechTimes e dev.to corroboraram a cronologia e o alcance na sua própria cobertura do incidente.

A causa foi um proxy no seu limite, não uma implementação com falhas

O post-mortem do GitHub afirma claramente que a falha não foi causada por uma implementação de código ou configuração; foi uma falha de capacidade e monitorização dentro da própria infraestrutura de rede da empresa. O gatilho foi um proxy sidecar de service mesh da Istio num centro de dados em Central US que atingiu o seu limite de concorrência quando o tráfego chegou num novo padrão de pico para o qual o sistema não estava dimensionado. Um sidecar de service mesh fica junto de cada instância de serviço para gerir o seu tráfego de rede, pelo que, quando um atinge um limite rígido sob carga inesperada, tudo o que é encaminhado através dele falha de uma só vez em vez de se degradar de forma gradual.

Um alerta mal configurado fez com que ninguém o visse a chegar

Uma política interna de monitorização estava mal configurada e não alertou a equipa de engenharia do GitHub quando o proxy sidecar se aproximava do seu limite de concorrência, pelo que o alerta que deveria ter desencadeado uma resposta antes de os utilizadores notarem algo simplesmente nunca disparou. Essa lacuna pesa tanto quanto o próprio limite de concorrência: um limite de capacidade detetado a tempo é uma atualização silenciosa, um limite detetado apenas depois de os utilizadores verem erros torna-se um incidente de várias horas. O GitHub afirma que corrigir essa lacuna de monitorização faz parte do "work ahead" referido no título do post-mortem.

As próprias retries do GitHub, sobretudo do VS Code, agravaram a falha

A lógica otimista de retries do lado do cliente em todo o ecossistema do GitHub transformou um proxy sobrecarregado numa cascata que atingiu toda a plataforma, e o GitHub apontou uma tempestade de retries de clientes do VS Code como um fator importante na gravidade da falha. Quando um pedido falha e um cliente volta a tentar de imediato sem esperar, não falha apenas outra vez, acrescenta mais um pedido a um sistema já sobrecarregado, e multiplicado por milhões de instalações do VS Code a contactar o GitHub em segundo plano, esse padrão transformou um problema de proxy contido num problema de toda a plataforma. É este pormenor que transforma o incidente, de uma história sobre a infraestrutura do GitHub, numa história sobre a forma como qualquer cliente de qualquer API deveria ser construído.

Para qualquer empresa com o pipeline a passar pelo GitHub, foram 8 horas de black-out

A maioria das empresas vê uma falha do GitHub como um incómodo para programadores, algo de que se queixam enquanto esperam, mas para qualquer empresa que tenha integrado silenciosamente o GitHub Actions e o Copilot no seu pipeline de lançamento, 7 horas e 47 minutos sem GitHub são 7 horas e 47 minutos durante os quais não é possível lançar uma correção urgente, não é possível integrar uma correção de segurança e, se o Copilot fizer parte do fluxo de trabalho, perde-se uma ferramenta de codificação assistida por IA a meio de uma tarefa. Trata-se de um risco de concentração num único fornecedor escondido dentro do que parece ser "simplesmente usar o GitHub", e que não aparece em nenhuma linha de orçamento como aconteceria com uma subscrição de software. A lição mais afiada é a tempestade de retries: se o próprio software cliente do GitHub agravou uma falha ao tentar novamente de forma agressiva sem esperar, qualquer empresa que esteja a construir os seus próprios sistemas contra API de terceiros deveria auditar a sua própria lógica de retries à procura do mesmo defeito, em vez de arquivar isto como sendo apenas um problema do GitHub.

Leia a seguir: O Agente de IA da Wiz Pirateou a Snowflake e Acusou o Copilot  |  O Seu Segundo Alojador Git Ligou-se Sozinho