GitHub's failure on August 17: lessons for your CI/CD

O que foi a falha do GitHub em 17 de agosto

Em 17 de agosto de 2026, o GitHub enfrentou uma indisponibilidade que durou 7 horas e 47 minutos. O problema atingiu o site, a autenticação, as APIs, o GitHub Actions, os pull requests, as issues e o Copilot.

O próprio GitHub informou que a falha começou quando o tráfego chegou a um novo pico e um componente crítico da infraestrutura, localizado no datacenter da região Central dos Estados Unidos, não conseguiu acompanhar a demanda. A pressão de capacidade se espalhou para outros serviços.

O incidente importa para qualquer equipe brasileira que dependa de GitHub para publicar código, executar pipelines ou receber alterações. A lição não é abandonar a plataforma, mas reconhecer que uma dependência central precisa de cópia local, observabilidade e um plano de recuperação testado.

Como a falha se espalhou

Quando um componente de infraestrutura perde capacidade, o efeito pode aparecer em serviços que parecem independentes. Autenticação, API, Actions e a interface web compartilham caminhos de rede e sistemas de suporte. Se um desses caminhos fica saturado, o usuário percebe erros em várias áreas ao mesmo tempo.

A recuperação também teve uma dificuldade conhecida em sistemas distribuídos: alguns serviços do Copilot entraram em um loop de novas tentativas no cliente. Os retries aumentaram o tráfego durante a recuperação e precisaram ser controlados antes que o tráfego pudesse ser restaurado com segurança.

Esse mecanismo é chamado de retry storm. Uma aplicação que tenta novamente sem limite, sem intervalo crescente e sem orçamento de tentativas pode transformar uma falha parcial em uma onda de novas requisições. O resultado é mais carga justamente quando o sistema já está vulnerável.

for tentativa in 1 2 3; do
  resposta=$(curl -sS -o /dev/null -w "%{http_code}" https://api.exemplo.com/health)
  [ "$resposta" = "200" ] && break
  sleep $((tentativa * 2))
done

Um retry responsável combina limite de tentativas, espera crescente e uma condição clara para desistir. Em produção, também é importante registrar o motivo da repetição para diferenciar indisponibilidade externa de erro no próprio aplicativo.

O que o GitHub oferece e por que a interrupção pesa

O GitHub reúne repositórios Git, colaboração por pull requests, issues, APIs e automação com GitHub Actions. Para muitas equipes, essas peças formam uma cadeia contínua que começa no commit e termina no deploy.

O GitHub Actions é especialmente sensível a incidentes porque executa testes, builds, migrações e publicações. Quando os runners ou a API ficam indisponíveis, o código pode continuar existindo no computador do desenvolvedor, mas o fluxo de entrega deixa de avançar.

A plataforma também concentra autenticação e comunicação do projeto. Se o login falha, a equipe pode perder acesso ao repositório, aos secrets e às telas de acompanhamento ao mesmo tempo. Esse é o motivo para tratar o GitHub como uma dependência operacional, não apenas como um site de hospedagem de código.

• Repositórios: armazenam histórico, branches e tags do projeto.
• Pull requests: organizam revisão, discussão e integração de mudanças.
• Actions: automatizam testes, empacotamento e deploy.
• APIs: conectam ferramentas internas ao fluxo de desenvolvimento.

Como começar: prepare seu fluxo em etapas

O primeiro passo é descobrir onde o seu processo realmente depende do GitHub. Liste os comandos, automações e serviços que precisam de autenticação, acesso à API, download de artefatos ou execução de workflows.

Depois, mantenha um clone local atualizado para cada repositório crítico. Em projetos importantes, crie também um bundle do Git. Ele guarda branches e referências em um único arquivo que pode ser copiado para um armazenamento independente.

git fetch --all --prune
git bundle create backup-repos.bundle --all
sha256sum backup-repos.bundle

Por fim, documente o que fazer durante uma indisponibilidade. Defina quem comunica o incidente, onde fica o último artefato, como bloquear um deploy automático e qual serviço alternativo pode receber uma publicação emergencial.

Exemplo prático: um runbook para o dia do incidente

Imagine que o seu time precisa publicar uma correção e o GitHub não responde. Antes de repetir o comando várias vezes, consulte a página de status e confirme se o erro também ocorre fora da sua rede. Essa distinção evita perder tempo investigando DNS, VPN ou credenciais locais quando a origem é externa.

Se o código já está no clone local, preserve o estado atual com uma branch e gere um bundle. Se o deploy precisa continuar, use o artefato produzido pelo último pipeline aprovado, desde que sua política de segurança permita a promoção sem uma nova execução.

git status --short
git branch incidente-GitHub-2026-08-17
git bundle create incidente-GitHub.bundle --all
sha256sum incidente-GitHub.bundle

Depois que o serviço voltar, não libere tudo de uma vez. Valide autenticação, API, Actions e o acesso aos artefatos. Reexecute os workflows com atenção para evitar duas publicações do mesmo commit ou uma migração repetida.

Comparação com alternativas

Usar outra plataforma como GitLab ou Bitbucket pode reduzir a dependência de um único fornecedor, mas não elimina a necessidade de operar bem. Cada alternativa também tem APIs, runners, autenticação e serviços de armazenamento que podem falhar.

Um forge auto-hospedado, como uma instalação própria de GitLab ou Gitea, oferece mais controle sobre dados e disponibilidade local. Em troca, a equipe assume atualizações, backups, segurança, armazenamento, observabilidade e resposta a incidentes.

Para a maioria dos times pequenos, a melhor escolha é manter o GitHub como plataforma principal e criar uma cópia independente dos repositórios e artefatos críticos. Times maiores podem combinar espelhamento periódico com um segundo provedor e uma política de failover.

• GitHub: bom ecossistema e integração ampla, com dependência de serviços hospedados.
• GitLab ou Bitbucket: alternativa de plataforma, útil quando a organização já usa seu ecossistema.
• Forge próprio: mais controle, mas exige operação contínua e responsabilidade integral.

Pontos positivos e limitações da lição

O ponto positivo do incidente é tornar visível uma dependência que costuma ficar escondida. Um clone local, um bundle e um runbook são medidas simples que aumentam a capacidade de resposta sem exigir uma migração imediata.

Outra vantagem é revisar os retries entre serviços. Limites, backoff, circuit breakers e timeouts reduzem a chance de uma falha externa derrubar também o seu sistema. Essas práticas são úteis mesmo quando o provedor nunca fica indisponível.

A limitação é que nenhum backup substitui completamente a plataforma. Um bundle preserva o Git, mas não reproduz automaticamente issues, secrets, comentários, regras de proteção, runners e artefatos. A estratégia precisa separar o que é essencial para recuperar o código do que é necessário para recuperar toda a operação.

Casos de uso reais

Desenvolvedor solo: um bundle semanal e uma cópia dos arquivos de configuração evitam que uma indisponibilidade apague um dia inteiro de trabalho. O objetivo é voltar a editar e testar localmente sem esperar o provedor.

Startup em crescimento: o time pode manter o GitHub como origem, mas guardar imagens de contêiner e artefatos de release em um local independente. Assim, um pipeline parado não impede uma ação de emergência já aprovada.

Empresa com vários times: a equipe de plataforma deve definir limites de retry, alarmes e um inventário de dependências. Também pode manter um espelho dos repositórios críticos e ensaiar uma recuperação sem acesso à interface web.

Consultoria ou agência: um runbook por cliente reduz a confusão quando um deploy falha durante uma janela de publicação. A documentação precisa informar o último commit, o artefato válido, o contato responsável e o procedimento de rollback.

Dicas e boas práticas

Comece pela continuidade do código. Repositórios críticos devem ter clones atualizados, tags de release e backups com checksum. Não espere um incidente para descobrir que o backup não abre.

Depois, cuide do comportamento da aplicação. Toda chamada a serviço externo deve ter timeout, limite de retries e logs com correlação. Repetir para sempre mascara a causa e pode piorar a saturação.

Por último, monitore o que realmente bloqueia o negócio. Não olhe apenas para o status geral do provedor: verifique autenticação, API, filas de CI, artefatos e a última versão publicada.

Vale a pena mudar sua estratégia?

Vale a pena revisar a estratégia, mas não necessariamente trocar de plataforma. O GitHub continua sendo útil para colaboração e automação; o problema está em depender dele sem cópias, sem limites de retry e sem um caminho de recuperação.

Para um projeto pequeno, comece hoje com clone local atualizado, bundle, checksum e uma página de runbook. Para uma equipe maior, acrescente espelhamento, inventário de dependências, monitoramento sintético e um exercício de failover.

O próximo passo é medir o tempo de recuperação de um repositório crítico sem acesso ao GitHub. Se a resposta for "não sabemos", esse é o trabalho mais importante antes do próximo incidente.