Apagão do GitHub afetou downloads, Actions e Copilot; veja o que se sabe

Mais tarde, a empresa informou que havia identificado o componente envolvido e tomado medidas corretivas. Uma atualização publicada às 12h36 no horário de verão do leste dos EUA afirmou que a plataforma apresentava fortes sinais de recuperação, embora ainda não estivesse totalmente estabilizada.

A recuperação não ocorreu ao mesmo tempo em todos os serviços. Os registros de status mostraram os principais recursos voltando à operação enquanto o Copilot ainda enfrentava problemas de autenticação em algumas aplicações. Outros relatos situaram o fim da interrupção geral por volta de 21h15 UTC, o que tornou o incidente consideravelmente mais longo do que o período inicial de degradação mais severa.

Qual foi a dimensão do apagão?

As taxas divulgadas pelo próprio GitHub oferecem o retrato mais claro do impacto:

• Experiência web e tráfego de API: aproximadamente 20% de erros.
• Downloads de arquivos compactados e conteúdo bruto de repositórios: aproximadamente 50% de erros.
• Serviços para desenvolvedores: Pull Requests, Issues, Actions, Webhooks, operações Git e Pages ficaram degradados ou indisponíveis em diferentes momentos.
• Assistência de programação com IA: o GitHub Copilot foi afetado e continuou apresentando problemas depois que vários serviços centrais já haviam se recuperado.
• Identidade empresarial: houve relatos de impacto em autenticação SAML e OIDC, provisionamento SCIM e Team Sync — recursos que ajudam organizações a autenticar usuários e administrar acessos.

Esses percentuais representam taxas de erro, não a parcela exata de usuários que perdeu acesso ao GitHub. Uma taxa de 20% de erros na API não significa que exatamente 20% dos clientes ficaram offline. Da mesma forma, os 50% se referem às solicitações de download afetadas, e não a todo o tráfego dos repositórios.

Por que uma segunda-feira de manhã agravou o impacto

O incidente começou na manhã de uma segunda-feira nos Estados Unidos, coincidindo com o início da semana de trabalho de muitas equipes de engenharia. Esse horário é particularmente sensível porque acesso ao código, revisão de alterações, integração contínua e automação de deploy costumam fazer parte do primeiro ciclo de atividades do dia.

Actions, Pull Requests, APIs e Webhooks estavam entre os serviços afetados. Por isso, as equipes podiam encontrar falhas em várias etapas conectadas do fluxo de desenvolvimento, em vez de enfrentar apenas um recurso isolado.

Os números de plataformas que monitoram interrupções também variaram conforme o horário e o método de contagem. Um relato mencionou mais de 10 mil notificações no Downdetector até 8h12 no horário do Pacífico, enquanto outro apontou um pico de quase 3 mil registros. Esses valores não devem ser interpretados como uma contagem precisa de usuários afetados: serviços desse tipo contabilizam relatos enviados, e os totais mudam conforme a região, o momento e a metodologia utilizada.

O que o GitHub fez — e o que ainda não explicou

As atualizações públicas do GitHub confirmam três etapas da resposta:

1. Engenheiros investigaram problemas elevados de desempenho em vários serviços.
2. A empresa identificou um componente problemático e tomou medidas corretivas.
3. O GitHub continuou aplicando mitigações depois que os principais serviços começaram a se recuperar, incluindo ações contra falhas esporádicas de autenticação do Copilot.

As evidências disponíveis não identificam qual era o componente, não descrevem a ação corretiva exata e não comprovam que pressão de capacidade tenha causado especificamente esse incidente. O crescimento do tráfego impulsionado por IA e as limitações de infraestrutura fazem parte da discussão mais ampla sobre confiabilidade do GitHub, mas não devem ser apresentados como a causa confirmada do apagão de 17 de agosto antes da publicação do relatório pós-incidente.

Como o incidente se encaixa nos problemas de confiabilidade de 2026

O apagão ocorreu depois de um período difícil para a disponibilidade da plataforma. O relatório de disponibilidade do GitHub registrou oito incidentes em julho. Um deles, em 8 de julho, durou mais de sete horas e afetou a interface web, as APIs REST e GraphQL, Actions, Packages, Copilot e operações Git em alguns ambientes do Enterprise Cloud.

A empresa também descreveu um desafio estrutural maior. Em suas comunicações sobre disponibilidade, o GitHub afirmou que o tráfego crescia rapidamente, em grande parte impulsionado por fluxos de desenvolvimento assistidos por IA e por agentes. As medidas anunciadas incluíam transferir mais capacidade para o Azure, separar serviços e reduzir pontos de falha compartilhados.

A escala do plano chama atenção. Reportagens sobre a infraestrutura do GitHub afirmaram que a meta original de ampliar a capacidade em dez vezes foi revisada para uma necessidade de projetar a plataforma para 30 vezes a escala então existente. Outros relatos descreveram esforços envolvendo Azure e capacidade adicional em múltiplas nuvens, incluindo a AWS — embora esses planos, por si só, não expliquem o incidente de agosto.

Esse contexto torna o apagão relevante para além de uma manhã problemática. O GitHub não é apenas um lugar para armazenar repositórios Git: também funciona como camada de colaboração, plataforma de automação, sistema de identidade e serviço de programação com IA. Quando dependências compartilhadas falham, um único incidente pode interromper ao mesmo tempo o acesso ao código, revisões, builds, deploys, Webhooks e assistência de programação.

O que as organizações podem aprender

O apagão não prova que os desenvolvedores estejam prestes a abandonar o GitHub, e as evidências não sustentam a previsão de uma onda iminente de migrações. O episódio, porém, mostra por que organizações que dependem da plataforma para entregar software em produção deveriam revisar suas premissas de continuidade.

Entre as medidas práticas estão manter backups ou espelhos dos repositórios, usar configurações de CI/CD portáteis, documentar procedimentos de release emergencial e garantir que as equipes saibam operar quando SSO, Webhooks ou runners hospedados estiverem indisponíveis. Essas ações não eliminam o risco de depender de uma plataforma, mas podem reduzir o alcance do próximo incidente.

A avaliação definitiva sobre 17 de agosto dependerá do relatório pós-incidente do GitHub. Até que essa análise seja publicada, a conclusão mais segura é mais limitada: o GitHub sofreu uma interrupção ampla e em cascata, com efeitos severos sobre downloads de repositórios e fluxos de trabalho conectados; a recuperação ocorreu por etapas; e a empresa ainda não explicou publicamente a falha subjacente.