O GitHub enfrentou uma indisponibilidade de 7 horas e 47 minutos em 17 de agosto. O incidente afetou o site, autenticação, GitHub Actions, APIs, pull requests, issues e Copilot, interrompendo desenvolvimento e entrega de software em organizações de vários países.1
Segundo a análise publicada pela empresa, um pico inédito de tráfego encontrou um componente crítico que não conseguiu escalar no data center Central US. A pressão de capacidade se espalhou pelos serviços. Durante a recuperação, erros em partes do Copilot ainda provocaram um ciclo de novas tentativas no cliente e elevaram o tráfego.
O episódio não prova que equipes devam abandonar a plataforma. Ele mostra algo mais útil: um repositório disponível em um provedor central pode ser simultaneamente arquivo de código, identidade, revisão, automação, distribuição de dependências e porta de produção. Quando essas funções param juntas, ter o código clonado em um notebook é apenas o começo da continuidade.
Uma cópia do Git não preserva toda a entrega
O histórico Git contém arquivos, branches, tags e revisões. O próprio GitHub recomenda um clone espelho como opção de backup e orienta buscar separadamente objetos do Git LFS quando eles existirem.2
Esse backup é necessário, mas não inclui automaticamente secrets, variáveis de ambiente, regras de proteção, permissões, runners, artefatos, pacotes, issues e decisões registradas em pull requests. Arquivos de migração também podem estar no repositório sem que exista uma cópia recente do banco de dados que eles transformam.
Continuidade exige listar os elementos necessários para publicar uma versão. Código-fonte, dependências, imagem de container, configuração, credenciais de emergência, banco, DNS e procedimento de rollback precisam ter origem e restauração conhecidas. Cada item deve indicar responsável, frequência de cópia, retenção e teste de recuperação.
O pipeline não pode ser a única porta para produção
GitHub Actions tornou a entrega repetível, auditável e integrada ao repositório. A mesma conveniência pode criar uma dependência rígida quando a organização não consegue executar o processo fora do plano de controle do GitHub.
Uma estratégia de contingência não precisa manter dois sistemas completos ativos o tempo todo. Ela precisa preservar uma rota proporcional ao risco. Para um site institucional, pode ser suficiente ter o último artefato aprovado e um procedimento autenticado de republicação. Para um serviço crítico, pode ser necessário construir e assinar releases em um executor alternativo.
O ponto central é separar produção e preparação. Se o artefato já foi criado, testado e armazenado em um registro independente, uma indisponibilidade do sistema de CI não deveria obrigar a recompilar tudo. Deploy por digest, promoção entre ambientes e rollback para versão conhecida reduzem dependências durante o incidente.
Dependências e pacotes também fazem parte do risco
Mesmo com o repositório local, uma build pode falhar ao tentar baixar pacotes, actions reutilizáveis, imagens base ou arquivos de release. A cadeia de entrega depende de vários registros e URLs que costumam ficar invisíveis enquanto tudo funciona.
Projetos maduros usam lockfiles, fixam actions por versão ou hash, mantêm cache controlado e sabem quais dependências precisam de espelho. Imagens de produção devem ser imutáveis e permanecer disponíveis pelo prazo necessário para rollback. Pacotes internos precisam de backup e política de retenção própria.
A documentação do GitHub alerta que arquivos de migração da plataforma não incluem todos os dados, como objetos LFS, discussões e packages, e não têm um caminho documentado de restauração no GitHub. Isso reforça que arquivamento e recuperação operacional são objetivos diferentes.2
Identidade pode parar antes do código
O incidente atingiu autenticação, além de APIs e automações. Em uma organização que usa uma única identidade federada para código, nuvem, comunicação e observabilidade, uma falha central pode impedir até o acesso aos instrumentos de resposta.
Contas de emergência precisam existir com privilégios mínimos, proteção forte e uso monitorado. Elas não devem depender do mesmo provedor de identidade que pretendem contornar. Chaves e tokens também não podem ficar apenas dentro do sistema de CI indisponível.
Esse acesso excepcional exige governança: armazenamento seguro, dupla custódia quando necessário, teste periódico e revogação depois do uso. Um atalho permanente e compartilhado criaria um risco maior do que a indisponibilidade que pretende resolver.
O runbook deve começar pela decisão de negócio
Durante uma pane ampla, insistir em publicar pode não ser a melhor resposta. A equipe precisa saber quais mudanças podem esperar, quais incidentes exigem correção imediata e quem autoriza o modo de contingência.
Um runbook útil registra sinais, impacto, responsáveis, canais alternativos, artefato liberado, sequência de deploy, validação e retorno ao fluxo normal. Também define o que não fazer. Reconstruir produção a partir de uma máquina pessoal, desativar controles ou trocar DNS sem critério pode ampliar o incidente.
Exercícios curtos revelam dependências escondidas. A organização pode simular a indisponibilidade do GitHub, tentar localizar o último release, restaurar um clone espelho, acessar o provedor e comprovar rollback. O resultado deve medir tempo de recuperação e lacunas, não apenas marcar que o teste ocorreu.
Disponibilidade do fornecedor não substitui resiliência própria
O GitHub informou ações para melhorar capacidade, isolamento e recuperação. Essas medidas importam, mas nenhum fornecedor consegue definir sozinho o impacto que sua indisponibilidade terá em cada cliente.1
A resposta equilibrada é manter a produtividade da plataforma e retirar dela os pontos únicos de falha que ameaçam o negócio. Backup restaurável, artefato independente, acesso de emergência e runbook testado formam uma base mais realista do que duplicar toda a infraestrutura.
A pane de agosto deixou uma medida concreta para equipes de software: se a plataforma ficar indisponível por um dia, elas conseguem proteger o código, corrigir uma falha urgente e colocar no ar uma versão já aprovada sem improvisar? A continuidade começa quando essa resposta é demonstrada.
- GitHub, "The August 17 outage, and the work ahead", 20 ago. 2026. ↩
- GitHub Docs, "Backing up a repository", acesso em 20 ago. 2026. ↩