GitHub mostra dificuldade para manter até 99,9% de disponibilidade

• Com as falhas frequentes de serviço no GitHub se acumulando recentemente, a situação indica que está difícil alcançar não apenas o padrão do setor de “5 nines (99,999%)”, mas até mesmo “3 nines (99,9%)”
• Em 9 de fevereiro, recursos principais como Actions, Pull Request, notificações e Copilot sofreram falhas ao mesmo tempo, e alguns serviços tiveram atrasos de várias horas
• Devido a um problema de propagação de política do Copilot, alguns usuários tiveram erro na exibição de modelos até a manhã de 10 de fevereiro
• Depois que o GitHub alterou a estrutura da página de status, ficou mais difícil rastrear a disponibilidade dos últimos 90 dias, e dados não oficiais mostram até momentos em que a disponibilidade ficou abaixo de 90%
• Embora o SLA do Enterprise Cloud especifique 99,9% de uptime, isso não é garantido na prática para todos os usuários, aumentando a necessidade de estratégias operacionais voltadas para lidar com downtime

---

Queda de disponibilidade e falhas frequentes de serviço no GitHub

• Em meio à normalização de falhas frequentes em serviços de nuvem, o GitHub também vem enfrentando problemas de estabilidade
  • Surgem expressões como “é raro passar um dia sem falha”, e comenta-se que está difícil alcançar não apenas “5 nines (99,999%)”, mas até mesmo “1 nine (90%)”
• Em 9 de fevereiro (UTC), recursos principais do GitHub como Actions, Pull Request, notificações e Copilot sofreram falhas
  • O GitHub informou por volta de 15:54 que “alguns serviços estão com problemas” e anunciou que o atraso nas notificações chegava a cerca de 50 minutos
  • Às 17:57, o atraso havia caído para cerca de 30 minutos, e às 19:29 foi informado que a situação havia sido normalizada
• A falha relacionada ao Copilot persistiu por mais tempo
  • De 9 de fevereiro às 16:29 até 10 de fevereiro às 9:57, alguns usuários enfrentaram um problema de propagação de política do Copilot
  • Com isso, foi relatado que modelos recém-ativados não apareciam para os usuários
• O GitHub alterou a estrutura da página de status, tornando mais difícil rastrear a disponibilidade dos últimos 90 dias
  • Os detalhes ainda são fornecidos, mas o formato mudou de forma que ficou mais difícil entender visualmente a tendência geral de uptime
  • Em dados da página não oficial de recuperação (mrshu.github.io/github-statuses/), é possível ver que em certo momento de 2025 a disponibilidade caiu abaixo de 90%
• O SLA do Enterprise Cloud do GitHub especifica 99,9% de uptime, mas isso não é garantido para todos os usuários
  • No setor, “5 nines” é visto como um padrão ideal, mas algumas empresas são avaliadas como estando em uma realidade em que é difícil até mesmo manter 90%
  • Essa situação sugere que os clientes precisam preparar planos operacionais assumindo a possibilidade de downtime

Contexto e casos relacionados

• O GitHub vem enfrentando recentemente várias controvérsias ligadas a recursos de IA e mudanças de política
  • Avaliação de um “kill switch” de IA para bloquear código em Pull Requests

  • Retirada do plano de preços para runners self-hosted

    • Há o caso em que o projeto da linguagem Zig deixou o GitHub citando a política centrada em IA da Microsoft
    • Junto desses episódios, a queda na estabilidade do serviço vem atuando como fator que aumenta a insatisfação da comunidade de desenvolvedores

Conclusão

• As falhas recentes do GitHub expõem um problema de disponibilidade em que está difícil atingir até mesmo “três noves” (99,9%)
• Com a instabilidade contínua de recursos centrais como o Copilot, garantir a confiabilidade de plataformas de desenvolvimento baseadas em nuvem surge como uma tarefa importante
• A necessidade de definir estratégias para lidar com downtime volta a ser enfatizada

[elbanic]

o GitHub é um serviço gratuito, então esperar alta disponibilidade dele já é meio...

[cosine20]

Mesmo se o KakaoTalk ficar fora do ar, você vai dizer a mesma coisa...

[malkeu]

Acho que dá para resolver com git reset --hard.

[master6559]

Se o GitHub só não tivesse quedas, do jeito que está agora já estaria bom.

[GN⁺]

Opiniões do Hacker News

• Os problemas de uptime do GitHub são claramente sérios, mas acho exagerado dizer que “o GitHub inteiro caiu” só porque nem todos os recursos pararam ao mesmo tempo
  Eu quase não uso o Copilot, então não ligo muito quando esse serviço cai com frequência
  O que realmente importa é a estabilidade dos recursos centrais, como Git, site, API e Actions

  • Concordo. Mas, nos últimos 90 dias, nenhum serviço individual sequer atingiu 3x9 (99,9%) de uptime
    Segundo o Enterprise SLA do GitHub, cada serviço deveria garantir no mínimo 99,9%, mas os números reais podem ser vistos aqui
  • É verdade que dizer “o GitHub caiu” é um exagero, mas na prática até a API está em apenas 99,69%, ou seja, só dois noves
    O Copilot está no nível de um nove, e o mesmo vale para serviços centrais como Git e Actions
  • Esta empresa faz parte do portfólio de uma empresa global de 1 trilhão de dólares
    Uma empresa com esses recursos deixar os clientes à própria sorte não tem desculpa
  • Hoje em dia, esse papo de “5 nines” das grandes empresas é quase uma ilusão
    Na prática, até respostas com erro entram na conta como “funcionando normalmente”
    Casos de 99,999% reais, como no setor de redes, são raros, e na maioria das vezes o que existe são truques de fatiamento de dados para manter a página de status verde

• Fiquei apreensivo desde que o CTO do GitHub anunciou, em 2025, que faria a “migração completa para o Azure” para melhorar a estabilidade
  Antes, a comunidade gritava por “mais recursos mais rápido”, mas agora o mais urgente é estabilidade e confiabilidade

  • Mesmo assim, o GitHub continua lento até para adicionar recursos novos
  • Se você não depende só de plataformas grandes, existem alternativas menores e estáveis a ponto de serem entediantes
  • Entrei nessa época, e achava fascinante simplesmente poder compartilhar meus repositórios publicamente
  • No geral, a estabilidade do setor melhorou, mas hoje há inúmeras dependências interligadas, então basta um ponto falhar para tudo balançar
  • Fico até torcendo para que, na migração completa para o Azure, eles esqueçam do acesso via IPv6

• O GitHub está enfrentando uma tempestade perfeita: migração para o Azure, mudanças de infraestrutura baseadas em IA e explosão de tráfego de IA
  Em projetos populares, poucos minutos depois de uma issue ser aberta, já aparecem dezenas de PRs gerados por IA
  É difícil absorver essa carga, e os “N 9s” antes e depois da IA têm níveis de dificuldade completamente diferentes

  • Exato. O GitHub originalmente não foi projetado tendo em mente esse tipo de ambiente de agentes de IA fora de controle

• Olhando a página de status do GitHub, o número real é 90,21%, ou seja, nível de um nove
  No arquivo de 2019, havia de 1 a 4 incidentes por mês; agora é praticamente um por dia

  • Esse número é ruim não só por downtime, mas também porque inclui degraded performance
  • Mesmo assim, brincam que ainda está melhor do que o status.claude.com do Claude

• Enquanto o GitHub está obcecado com recursos de IA, a segurança da plataforma está desmoronando
  Recentemente, a Aqua Security foi atacada e vários repositórios foram infectados, em um caso que explorou a vulnerabilidade de referência mutável do GitHub Actions
  O GitHub conhece esse problema e mesmo assim não o corrigiu

  • Como medida temporária, é melhor fixar (pin) a versão das Actions por hash
    Ex.: uses: actions/checkout@11bd7190...
    Para automação, veja mheap/pin-github-action
  • Acho que CI/CD ficou excessivamente enrolado por causa da complexidade baseada em YAML
    Antes, eu fazia deploy com Jenkins e deixava testes simples em scripts, mas agora virou um inferno de YAML distribuído
  • A segurança do GHA é tão grave que já dizem que ele “tem mais buracos que um queijo suíço”
  • Há até uma discussão da comunidade mostrando que esse problema vem sendo ignorado há anos

• Os 90% de uptime incluem todos os serviços, então a percepção real pode variar
  Mas até os 96,47% do Copilot ainda são só nível de um nove
  O GitHub recomenda usar “todos os recursos juntos”, mas quanto mais você faz isso, mais a confiabilidade despenca

  • Além disso, casos em que “está lento, mas funciona” não entram nas estatísticas
    Por exemplo, abrir um diff simples de PR pode levar mais de 30 segundos
  • Alguns incidentes também são reportados oficialmente com atraso
    Houve casos em que CI/CD, git e a função de PR pararam todos ao mesmo tempo
  • Comparando com os dados de 2019, a situação piorou em mais de 10 vezes
  • 96% é um número realmente terrível

• Tendo operado o GitHub Enterprise Server diretamente, esses problemas não me surpreendem
  Ele não atende requisitos básicos de alta disponibilidade, como sem suporte a active-active, sem upgrades sem downtime e sem rollback
  Se aparece um bug, não há alternativa além de restaurar backup, e nesse processo ocorre perda de dados
  Vender um produto assim para clientes premium é prova de descaso com disponibilidade

  • Nossa empresa também acabou desistindo do GHES e migrou para o GHEC

• A Microsoft tem talento para estragar produtos bons
  Skype é o exemplo clássico, e o mesmo vale para Windows, Notepad e Explorer
  A confusão de branding que vai de Office → Office 365 → Microsoft 365 → Copilot 365 também é grande

  • Parece que não falta muito para surgir um “GitHub for Business”

• Na nossa empresa, rodamos varreduras de segurança com GitHub Actions em cada PR
  Se o GitHub para, o gate de segurança também para, e os desenvolvedores fazem merge sem validação
  É assim que código vulnerável entra, mas o GitHub continua colocando gente só no Copilot

  • Teve até quem perguntasse se existe algum caso público sobre isso

• Ignorar IPv6 simboliza o descuido técnico do GitHub
  O problema maior é por que, mesmo nesse estado, ele ainda passa em auditorias de segurança
  A documentação de segurança do GitHub parece ser apenas protocolar

  • A qualidade da auditoria também é tão ruim quanto o nível da arquitetura